Better for what? Quickly churning out short-lived code to get the next round of funding, definitely. Writing (and _supporting_) "serious" projects over the long term, which also require high performance and/or high scalability, and can rip through terabytes of data if needed, definitely not. (All IMHO from lots of personal experience.)

Depends on your architecture. For scaling out rather than up, node and python are both far more performant because the footprint of minimum viable environment is much smaller. When you need to serve anywhere from 10-200,000 requests a minute on the same system quickly, and efficiently, lambda/azure functions/google app engine backed by node or python is pretty ideal.

As an example, when my org needs to contact folks about potential mass shooter events, our SLA is 90 seconds. If we did it in cloud with java or .net, it'd be too slow to spin up. If we did it on prem, we'd be charged insane amounts just for the ability to instantly respond to low frequency black swan events, or it'd be too slow. This is a real story of how a Java dev team transitioned to using node for scale in the first place.

Unlike Spring, JIT-based ASP.NET Core deployments spin up very fast (<2-5s for even large-ish applications, the main bottleneck is how fast it can open connections to dependencies, load configuration, etc.). For AOT variant, the startup time is usually below 200ms if we don't count the slowness of surrounding infra which applies to any language.

Of course CPU and RAM per request when compared to Node.js are not even close as Node is easily slower by a factor of 2-10.

It's good for things that don't involve ripping through terabytes of data, which is actually a lot of things. And idk if I'd use Java for that either.

I'm actually in this exact position right now. The vast majority of the time I write in TS but I have a need to process a whole lot of data so I went for Rust instead. Java is too much of a headache for me, personally

Yeah, Rust is fast, or you can go the other extreme with Python if you can put the heavy lifting on native modules.

They are not comparable. If anything, Kotlin is the equivalent in the JVM universe.

Kotlin is much closer to Java than to TypeScript even in terms of flexibility.

To me "Flexibility" sounds a lot like "The programmer always knows what he does".

Flexibility means for me more something more like, I think I know what I want to do but I also know that I'm probably wrong about that, so for now let's skip all the baroque protocol and let me make it work first. Once I'm sure I wrote what I actually wanted I'll add types if only to get rid of some bugs, consider edge cases and earn nice code completions and auto-generated docs.

Sure, but Kotlin is to Java as TypeScript is to JavaScript, which is the point I am making.

That’s not even remotely true.

TypeScript is a direct superset of JavaScript. Any valid JS is a valid TypeScript.

If Kotlin is what TS to JS, then so is Groovy, Scala, Clojure and other JVM languages.

> TypeScript is a direct superset of JavaScript. Any valid JS is a valid TypeScript.

Kotlin on JVM is a direct superset of Java on JVM. Any valid Java is also valid Kotlin at the bytecode layer.

> If Kotlin is what TS to JS, then so is Groovy, Scala, Clojure and other JVM languages.

Correct

Laughs in `: dynamic`