And no, there are no dependencies in package.json either (other than devDependencies for tests).
Which cumulatively means a competent developer could probably port it in less than one day.
They almost certainly spent longer working out how to deploy and integrate the original JS and ironing out the problems, than it would have taken to port it in the first place.
That’s sad.
And then they definitely spent much longer making their optimised fast path for simple expressions. Which they probably wouldn’t have bothered with if they had just ported the whole thing.
As for trying things like embedding V8… this is getting ridiculous.
I strongly suspect no one had actually looked at the code, but had just assumed all along that it was much more complex than it actually was.
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 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.
Which cumulatively means a competent developer could probably port it in less than one day.
They almost certainly spent longer working out how to deploy and integrate the original JS and ironing out the problems, than it would have taken to port it in the first place.
That’s sad.
And then they definitely spent much longer making their optimised fast path for simple expressions. Which they probably wouldn’t have bothered with if they had just ported the whole thing.
As for trying things like embedding V8… this is getting ridiculous.
I strongly suspect no one had actually looked at the code, but had just assumed all along that it was much more complex than it actually was.
The entire thing is a tragedy.