4 ms·

Something that annoys me about developing for V8 is that if you just write to the language spec, you'll hit all kinds of de-optimization cases. There's this con

Something that annoys me about developing for V8 is that if you just write to the language spec, you'll hit all kinds of de-optimization cases. There's this constant voice nagging at the back of my mind saying "don't use try/catch, it's slooow" or "don't use native promises, they're slooow". It's black magic just to keep track of what's fast and what's slow in the language, and it makes benchmarks even trickier and debatable than normal, if you can believe it. I hope this resolves that by optimizing the language more evenly.

endymi0n 9y ago
In the end, that's what killed JS in the backend for me for anything nontrivial that needs decent performance. It gets you with things like "with its JIT, your code might end up runnning faster than C" - and while that's true (!), it's going to come back biting your ass when anything falls out of the optimization loop. And this "something" always eventually happens, is often times a trivial one line change and will keep the whole team busy for three days until finally debugged and fixed. We're now building with Go. And while it's not the fastest language in synthetic tests, it's proved to be super predictable. If something breaks or leaks, it does so pretty hard (ever forgot a .Close() somewhere? :) and anything that's off is easy to discover and optimize with PProf. The V8 is an awesome and important piece of technology, but it's so complex that it's almost impossible to say why something worked out - or didn't.