| > port it in less than one day There's confidence and there's barking mad delusion. Here's the reality. I once ported 50k loc from Java to Go. Here are details: https://blog.kowalczyk.info/article/19f2fe97f06a47c3b1f118fd... Java => Go is easier than JavaScript => Go because languages are more similar. That was a very line-by-line port. Because I was paid by hour I took detailed notes. I spent 601 hours to port it. 50k / 601 = 83 lines ported per hour, 665 per 8 hour day, but really 500 per 6 working hours a day. No one does sustained 8 hours of writing code daily. I would consider that very fast and yet order of magnitude slower than your 5.5 k per day. 10x is not a mis-estimation, it's a full blown delusion. |
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.