I stand by my estimate, also having done interlanguage ports. I’m not saying any project of such size could be ported in one day, but this very much looks to be one of the more straightforward ones. Being a small project also accelerates things, as there are far fewer moving parts, concepts, &c. to keep in order.
I wouldn’t say that Java → Go is inherently easier than JavaScript → Go. There are more features in JavaScript that, if used, will make porting much harder, but they may well not be used. There’s a bit of async in this project, that’s probably the hardest bit, and maybe a little variadic calling. But comparing with your case, some challenges just aren’t there, such as inheritance and access control.
From a quick skim, I think perhaps 2000 lines will need no change beyond removing semicolons. And since this is mostly parser and AST sort of stuff, a lot of the rest is mechanical repetition and application of regular expression replacements or editor macros.
One note from your article, on fluent function chaining:
> This only works in languages that communicate errors via exceptions. When a function additionally returns an error, it’s no longer possible to chain it like that.
This is a Go limitation, not fundamental. (And Go is well known to be bad or at least verbose at error propagation.) Rust’s ? operator is an easy counterexample.
I wouldn’t say that Java → Go is inherently easier than JavaScript → Go. There are more features in JavaScript that, if used, will make porting much harder, but they may well not be used. There’s a bit of async in this project, that’s probably the hardest bit, and maybe a little variadic calling. But comparing with your case, some challenges just aren’t there, such as inheritance and access control.
From a quick skim, I think perhaps 2000 lines will need no change beyond removing semicolons. And since this is mostly parser and AST sort of stuff, a lot of the rest is mechanical repetition and application of regular expression replacements or editor macros.
One note from your article, on fluent function chaining:
> This only works in languages that communicate errors via exceptions. When a function additionally returns an error, it’s no longer possible to chain it like that.
This is a Go limitation, not fundamental. (And Go is well known to be bad or at least verbose at error propagation.) Rust’s ? operator is an easy counterexample.