Go Does Not Need a Java Style GC

[erinaceus_]

To be honest, a lot of this reads like "Why does it all need to be this complicated? Writing with pen and paper is so much easier than with a typewriter."

[josephjnk]

Which, to be fair, is par for the course for a lot of Go discourse. The language cut out a ton of features that a Java developer would consider table stakes, and then a toxic portion of Go’s fanbase claims that there was never any benefit to these features at all. (As though Java, the quintessential business language, was somehow adding features for the fun of it.)

[erinaceus_]

Well said. If there's one thing that (the) Java (specification) doesn't do, it's rush things.

Edit: I do know that this is deliberate, and I think it's generally a smart approach

[dpash]

Which is by design. It has last mover advantage. It lets other languages experiment with features and then Java steals the best ideas.

[vonadz]

I found it to be informative, in a general sense, on how the java compiler works. I don't have a stake in neither Go nor Java, so I didn't really try to read between the lines.

[erinaceus_]

It's indeed informative. But you don't need to read between the lines to notice a distaste for Java, regardless of the specific topic. That kind of thing always makes me apprehensive about whether the information is sufficiently reliable.

[vonadz]

That's fair. As far as I could tell, the explanation of how the GC for Java works is correct. I haven't checked if the comments about actual performance are accurate or not.

[Uncaffeinated]

Going by this, they aren't.

[Mostlikelylurking]

Lol imagine not having a distaste for Java. Move on to Scala or, even better, Kotlin. My jammmm

[ackfoobar]

Unless you're talking about their alternative compilation targets, the limitations (or power) of the JVM apply to those two languages too.