Hacker News new | ask | show | jobs
by dontlaugh 377 days ago
That still seems like a long term mistake to me, an evolutionary dead end.
2 comments

Does it matter? Today, they get a 10x improvement by switching. Mission accomplished.

X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.

It can be a limitation much faster than that. They are in a situation where they won’t be able to improve further by much due to unavoidable costly abstractions in Go. If they’d picked something lower level there would be more possible after this first switch.
My mistake, I shouldn't have put a number there since that is what you focused on.

Rewriting it in assembly is the way to go, but that has other tradeoffs.

I’m not focused on a number, I’m just pointing out Go’s optimisation potential is lower than other options.

Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.

FYI: I have no dog in this fight.

    > unavoidable costly abstractions in Go
Can you share some?
Implicit struct copies, garbage collection, interface dispatch, etc.
It absolutely was. All it takes is a quick look around other language ecosystems and JS itself.

Rust is an excellent language for embedding in other languages And underpinning developer tools.

That said, someday the new typescript binary will compile to WebAssembly, and it won’t matter much anyway.

There is that opposite approach, yes. Add low-level control to TypeScript and get it to compile to WebAssembly, then the compiler itself can be fast as well.

I suspect they wanted the compiler speed more than they wanted a WASM target, though.