The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
Java is doing it better (virtual threads + structured concurrency + immutable records and immutable value types).
Not to mention golang is not memory safe: <a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">https://www.ralfj.de/blog/2025/07/24/memory-safety.html
I don't think you understand the threading concurrency topic. Also memory safety is so far off base here, where's that coming from? Java does some stuff okay, but do you really want to defend the horrid JVM problems? Also why can't I have my memory back when it's not in use in tightly packed systems?
It's not great for everything and neither is Go. You can find a bit more context on that in some of the other threads.
The memory safety thing is just a moot out of scope contract. It seems moot to me every time someone shows up trying to push memory safety everywhere, that's a language to developer contract issue, not a functionality issue. When the contract of the language is such as that of Go vs Rust, the two languages are just offering different contracts. Rust just promises to hold your hand more than Go does.
Regarding the JVM and GC. Good luck with that? Every Java application I've seen in the wild when I supported JVM seemed to never release any ram it allocated. Ever. If it used 1G and even after free, the JVM decided that was going to be used again and wouldn't release it.
It would be hard to sell me on wanting to use Java again (people can pay me enough to do it, but I hate it). Which kinda sucks since Apache Foundation has a ton of really cool projects using it. Kotlin maybe, but I have no real use cases where it would be better than anything else I know right now.
> The memory safety thing is just a moot out of scope contract.
Data races are not common but when they do happen. I hate to debug them. Only thing worse than data races is data races causing SEGFAULTS.
> Every Java application I've seen in the wild when I supported JVM seemed to never release any ram it allocated. Ever.
You can say the same for Go. Nature of GC langs is they consume more memory than what is minimal. And in theory as a trade off they give you memory safety.
Go doesn't even give memory safety. If program is racy enough.
SamInTheShell · · focus · HN ↗
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
za3faran · · focus · HN ↗
Not to mention golang is not memory safe: <a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">https://www.ralfj.de/blog/2025/07/24/memory-safety.html
SamInTheShell · · focus · HN ↗
It's not great for everything and neither is Go. You can find a bit more context on that in some of the other threads.
Ygg2 · · focus · HN ↗
It's coming from Go. In presence of data races on interfaces, slices or maps your memory might get corrupted.
> Also why can't I have my memory back when it's not in use in tightly packed systems?
You can. You have to either set your GC to be more aggressive or you need to utilize value types more.
SamInTheShell · · focus · HN ↗
Regarding the JVM and GC. Good luck with that? Every Java application I've seen in the wild when I supported JVM seemed to never release any ram it allocated. Ever. If it used 1G and even after free, the JVM decided that was going to be used again and wouldn't release it.
It would be hard to sell me on wanting to use Java again (people can pay me enough to do it, but I hate it). Which kinda sucks since Apache Foundation has a ton of really cool projects using it. Kotlin maybe, but I have no real use cases where it would be better than anything else I know right now.
Ygg2 · · focus · HN ↗
Data races are not common but when they do happen. I hate to debug them. Only thing worse than data races is data races causing SEGFAULTS.
> Every Java application I've seen in the wild when I supported JVM seemed to never release any ram it allocated. Ever.
You can say the same for Go. Nature of GC langs is they consume more memory than what is minimal. And in theory as a trade off they give you memory safety.
Go doesn't even give memory safety. If program is racy enough.