[judofyr]

> Obviously, just from Java occupying the top 2 or 3 spots for popularity over the last 15 years -- Java's approach must be doing something right.

I'm not sure if this argument holds. Java's high memory usage is frequently cited as a downside of Java. GUI applications written in Java have a reputation of being memory-hungry, and I know plenty of people struggling with memory usage of server application (e.g. ElasticSearch). You will also find C/C++ on the same popularity lists…

That said, I do agree that a tracing GC is a better solution (for most programs) than reference counting these days. The improvements in the pause times by the Java GCs are really impressive, and the throughput is great. One example would be ESBuild: The author created a prototype in both Rust and Go, and found that the Go version was faster allegedly because Rust ended up spending a lot of time deallocating [source: https://news.ycombinator.com/item?id=22336284].

[cb321]

The default tracing Nim GC is capable of quarter-millisecond pause times while the new ARC/ORC stuff is more like single-digit microseconds: https://forum.nim-lang.org/t/5734

[DannyB2]

That is interesting.

[DannyB2]

> Java's high memory usage

I would rather optimize for performance and energy use at the cost of higher memory use.

See recent SN:

https://news.ycombinator.com/item?id=24642134

https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...

Memory is a one time capital cost and gets cheaper over time.

[imtringued]

High memory usage forces you to only run one JVM process. If you need to do something that doesn't require a significant amount of memory you can't use Java at all.

[darthrupert]

> Memory is a one time capital cost and gets cheaper over time.

Except if you're operating in the cloud.

[pjmlp]

True, yet not everyone is trying to be the next FAANG.

Besides, plenty of GC enabled languages support value types and ways to do deterministic deallocation, use the tools Luke.