←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 5 comments | 22 Aug 25 09:25 UTC | HN request time: 1.213s | source
Show context
the_duke ◴[22 Aug 25 11:46 UTC] No.44983331[source]▶
I personally don't like Go, and it has many shortcomings, but there is a reason it is popular regardless:

Go is a reasonably performant language that makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading - all thanks to the goroutine model.

There really was no other reasonably popular, static, compiled language around when Google came out.

And there still barely is - the only real competitor that sits in a similar space is Java with the new virtual threads.

Languages with async/await promise something similar, but in practice are burdened with a lot of complexity (avoiding blocking in async tasks, function colouring, ...)

I'm not counting Erlang here, because it is a very different type of language...

So I'd say Go is popular despite the myriad of shortcomings, thanks to goroutines and the Google project street cred.

replies(7): >>44983372 #>>44983413 #>>44983414 #>>44983469 #>>44983501 #>>44983524 #>>44983597 #
cogman10 ◴[22 Aug 25 12:02 UTC] No.44983469[source]▶
Slowly but surely, the jvm has been closing the go gap. With efforts like virtual threads, zgc, lilliput, Leyden, and Valhalla, the jvm has been closing the gap.

The change from Java 8 to 25 is night and day. And the future looks bright. Java is slowly bringing in more language features that make it quite ergonomic to work with.

replies(6): >>44983508 #>>44983613 #>>44983690 #>>44985179 #>>44986370 #>>44992635 #
1. clumsysmurf ◴[22 Aug 25 12:20 UTC] No.44983613[source]▶
Being able to create a self contained Kotlin app (JVM) that starts up quickly and uses the same amount of memory as the equivalent golang app would be amazing.
replies(1): >>44983981 #
2. gf000 ◴[22 Aug 25 12:50 UTC] No.44983981[source]▶
Graal native Image does that (though the compile time is quite long, but you can just run it on the JVM for development with hot reload and whatnot, and only do a native compile at release)
replies(1): >>44986041 #
3. clumsysmurf ◴[22 Aug 25 15:49 UTC] No.44986041[source]▶
From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.
replies(1): >>44986974 #
4. cogman10 ◴[22 Aug 25 17:04 UTC] No.44986974{3}[source]▶
Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it.

You can get a large portion of what graal native offers by using AppCDS and compressed object headers.

Here's the latest JEP for all that.

https://openjdk.org/jeps/483

replies(1): >>44987364 #
5. gf000 ◴[22 Aug 25 17:40 UTC] No.44987364{4}[source]▶
Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually.

Also, quite a few libraries have metadata now denoting these extra reflection targets.

But nonetheless you are right in general, but depends on your use case.