Comment by m_ke
6 hours ago
1. it's built for async 2. runs everywhere 3. interpreted, making it fast to iterate on 4. decent performance 5. most popular language, llms are decent at writing it
6 hours ago
1. it's built for async 2. runs everywhere 3. interpreted, making it fast to iterate on 4. decent performance 5. most popular language, llms are decent at writing it
An additional benefit of interpreted, I think, is to make plugins easier to distribute and incorporate. With a compiled language you’d need message passing or something.
dynamic linking was invented pretty long time ago
You know that dlopen does not compare.
JVM has real and virtual threads and arguably just as good if not better on all these points.
(I actually have/am writing a harness in Java fwiw, but mostly as a hobby/experimentation)
JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
The JVM has a fixed size heap which for me it is wasteful.
IMHO, Microsoft made the correct approach on .NET.
For LLMs, I prefer C# and C++ instead of TypeScript, JavaScript or Python as the static + compiled language factor keeps the coding agents on track. Plus, they have a true threading/async implementation.
2 replies →
and you could say the same if not better from C#. But those are now becoming niche languages and ecosystems. One for people around microsoft, azure, etc. The other around oracle solutions. There are still pretty interesting projects around it any of them, but they seem to be losing mindshare against other languages.
1 reply →
I hate nodejs and the npm ecosystem more than most, but Java, really?
But have you considered that java is gross and nodejs is sexy?
That actually don't like you're describing Python. I've been working on a couple JS/TS projects and it's like the models I use (Claude Sonnet and DeepSeek v4 Flash) continually struggle to do coherent work; I have to always keep close watch to reduce sloppiness. I go to Python and it's smooth sailing with minimal prompting (and reduced token burn) for acceptable outcomes.
aren't 3 and 4 a tradeoff though? Yes you have 3 but "decent performance" cannot be an extaled value as compared to "runs everywhere". If its used as a counter balance to 3 then it shouldn't be its own unique point basically saying 4 is true despite 3 in this case.
when you're waiting for network or LLM inference the raw performance doesn't matter at all
This line of thinking I feel like assumes it's the only program running on your computer. Using less of my CPU and memory means my computer can do more things in parallel, or even run more instances of the harness. My laptop is sweating when I got 5+ claude code sessions running.
2 replies →
You would think raw performance wouldn't be a problem given most of whats happening is waiting for network calls and streaming tokens.
But modern bloat manages perfectly well to make apps that wait for network calls run poorly enough to give you a bad experience.
This is so very, very incorrect.
yeah fair enough, my entire point is not about the application itself but the contradiction on using superlative terms for all points but a compromising/normal term for one. Like if performance is not revelant why include it in the list of benefits.
decent performance, lol! compared to what? a shell script? "i'll only take up 200MB of disk and 4GB of RAM to output flickering text on a terminal. boy this is high performance"
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration