Hacker News Reader

Comment by ASalazarMX | Hacker News Reader

In a world where AI supposedly can write in any language, Go is much better choice than TypeScript. Imagine contemplating for more than a few seconds a choice between simple, fast, cross-compilable language, and a TypeScript -> JavaScript -> Interpreter -> JIT stack.

If you don't know Go, it's more efficient to learn it than to waste the hardware resources of thousands to stay within JavaScript.

View on HN

'Waste of hardware resources'? Ok then write your apps in Rust.

If it doesn't matter, and for most applications it doesn't, then TypeScript is far more readable than Go - so use that.

Absolutely. And in this same thread I am noticing people offering Java (lol). Yeah, we all need 1.5s startup time for one-off scripts, surely.

Well, these days a small CLI program in Java (say, ls) starts up cold, runs, and terminates in ~70ms, not 1500ms, but yeah, sometimes 70ms is too long to wait for a script.

People never believe me when I say it but I start noticing scripts needing 75-100ms to start. Modern hardware is ultra fast; I want my programs to make full use of it. I got no patience for tech or people who keep insisting "it's not much, it'll not kill you". Well duh, obviously it will not but that's not the point and never was. I want stuff to work between my blinking my eyes and I have achieved that hundreds of times over the course of my career.

That's perfectly fine, and I totally understand people who don't want to sit and wait 70ms for their script to finish running (that 70ms is not the time it takes to start), but let's not turn a <40ms startup into 1.5s. Now, it is true that if you want to launch a minimal HTTP server in Java you may need to wait ~100ms, which may be too long for you, but is also a far cry from 1.5s.

It is, but I am still quoting what I saw before, it was not a fantasy. I don't deny it's likely better nowadays, sure, but I remain moderately skeptical because JVM is still a runtime that needs to boot.

Then again, Golang has one as well, though it does manage to start it up faster it seems.

You might be interested in OpenJDK's new ability to 'cache' classes to accelerate class loading. JEP 483: Ahead-of-Time Class Loading & Linking. It doesn't persist code generated by the JIT, but can improve startup time appreciably.

From https://openjdk.org/jeps/483 :

> This program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK 24 — an improvement of 42%.

Thank you, that's great. Back when I worked with Java this was but a pipe dream. Glad that they got to it!

Reply on news.ycombinator.com