3 ms·

> I will admit that the programming culture is different for many GC'd languages' communities, sometimes encouraging a very trashy programming style, which cont

> I will admit that the programming culture is different for many GC'd languages' communities, sometimes encouraging a very trashy programming style, which contributes to the perception that GC itself is the problem For some languages (I’m looking at you, Java), there’s not much of a way to program that doesn't generate a bunch of garbage, because only primitives are treated as value types, and for Objects, heap allocations can only be avoided if escape analysis can prove the object doesn’t outlast its stack frame (which isn’t reliable in practice.) (Edit: or maybe it doesn’t happen at all. Apparently escape analysis isn’t used to put objects on the stack even if they are known to not escape: https://www.beyondjava.net/escape-analysis-java https://www.beyondjava.net/escape-analysis-java) I honestly can’t imagine much of a way to program in Java that doesn’t result in tremendous GC pressure. You could technically allocate big static buffers and use a completely different paradigm where every function is static and takes data at a defined offsets to said buffers, but… nobody really does this and the result wouldn’t look anything like Java. Sometimes it’s appropriate to blame the language.

titzer 5y ago
> I’m looking at you, Java > Sometimes it’s appropriate to blame the language. Oh, I know, I was just being vague to be diplomatic. Java being generally trashy has been one of the major motivators for me to do Virgil. In Java, you can't even parse an integer without allocating memory.
_ph_ 5y ago
It is indeed a huge problem of Java, that it often makes it difficult to avoid generating garbage. However, one still can reduce it a lot if trying hard. And be it by reimplementing selected parts of the standard libraries. But the job of avoiding garbage is much easier in Go :)
Karrot_Kream 5y ago
Yeah not all languages are created equal. Working around Java's GC can be a huge pain (luckily the generational GC makes it okay performance-wise to generate metric tons of garbage). Luckily Go doesn't have this problem and it's a lot easier to avoid allocations in Go.
pjmlp 5y ago
Java made a huge mistake of not being like Oberon, Modula-3, Eiffel, Mesa/Cedar,.... However that doesn't make all GC languages equal and measured by Java's bad decisions at birth.
twhitmore 5y ago
You can run high-volume business and mid-level infrastructure (messaging) systems day-in day-out in Java, and struggle to see more than 0.1% CPU needed for garbage collection. The light-bulb idea here is about reliability, security and productivity. Managing memory manually a la C/ C++ is a proven disaster in all three respects. Maybe ten or fifteen years ago GC was costly, but these days it's highly efficient and not incomparable with programmatic allocation.

titzer 5y ago

> I’m looking at you, Java > Sometimes it’s appropriate to blame the language. Oh, I know, I was just being vague to be diplomatic. Java being generally trashy has been one of the major motivators for me to do Virgil. In Java, you can't even parse an integer without allocating memory.

_ph_ 5y ago

It is indeed a huge problem of Java, that it often makes it difficult to avoid generating garbage. However, one still can reduce it a lot if trying hard. And be it by reimplementing selected parts of the standard libraries. But the job of avoiding garbage is much easier in Go :)

Karrot_Kream 5y ago

Yeah not all languages are created equal. Working around Java's GC can be a huge pain (luckily the generational GC makes it okay performance-wise to generate metric tons of garbage). Luckily Go doesn't have this problem and it's a lot easier to avoid allocations in Go.

pjmlp 5y ago

Java made a huge mistake of not being like Oberon, Modula-3, Eiffel, Mesa/Cedar,.... However that doesn't make all GC languages equal and measured by Java's bad decisions at birth.

twhitmore 5y ago

You can run high-volume business and mid-level infrastructure (messaging) systems day-in day-out in Java, and struggle to see more than 0.1% CPU needed for garbage collection. The light-bulb idea here is about reliability, security and productivity. Managing memory manually a la C/ C++ is a proven disaster in all three respects. Maybe ten or fifteen years ago GC was costly, but these days it's highly efficient and not incomparable with programmatic allocation.