Really interesting news, and uniquely dismaying to me as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem.
My question has to do with Ryan's statement:
> We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript
I've experimented deeply in this area (maybe 15k hours invested in BABLR so far) and what I've found is that it's richly rewarding. Javascript is fast enough for what is needed, and its ability to cache on immutable data can make it lightning fast not through doing more work faster, but by making it possible to do less work. In other words, change the complexity class not the constant factor.
Is this a direction you investigated? What made you decide to try to move sideways instead of forwards?
> as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem
Have you considered the man-years and energy you're making everyone waste? Just as an example, I wonder what the carbon footprint of ESLint has been over the years...
Now, it pales in comparison to Python, but still...
I'm no more thrilled than you at the cost of running ESLint, but using a high-level language doesn't need to mean being wasteful of resources.
TS currently wastes tons of resources (most especially peoples' time) by not being able to share its data and infrastructure with other tools and ecosystems, but while there would be much bigger wins from tackling the systemic problem, you wouldn't be able to say something as glib as "TS is 10x faster". Only the work that can be distilled to a metric is done now, because that's how to get a promotion when you work for a company like Microsoft
If I could choose between Typescript speeding up 10x or all the surrounding tooling speeding up 20x, I'd take Typescript in a heartbeat. Slow type checking is the biggest pain point in my daily dev cycle.
Thank you Typescript team for chasing those promotions!
Really interesting news, and uniquely dismaying to me as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem.
My question has to do with Ryan's statement:
> We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript
I've experimented deeply in this area (maybe 15k hours invested in BABLR so far) and what I've found is that it's richly rewarding. Javascript is fast enough for what is needed, and its ability to cache on immutable data can make it lightning fast not through doing more work faster, but by making it possible to do less work. In other words, change the complexity class not the constant factor.
Is this a direction you investigated? What made you decide to try to move sideways instead of forwards?