pebal

Provide the GC name.

Every GC in Java involves synchronization points and the pausing of application threads.

It’s great that they were created for this purpose, but I have a faster allocator in non-moving GC engine in C++. And I don't have to moving gigabytes of data.

A moving GC does not provide the fastest allocation. This is one of the myths in the Java world.

ZGC is not pause-free. The only pause-free GC that exists is SGCL for the C++.

Rust could just as well have an optional tracing GC for shared ownership instead of ARC, potentially improving performance rather than reducing it. Having a GC doesn't inherently make a language slower.

I’m not saying it doesn't work. I’m saying it’s a waste of resources and won’t gain widespread popularity. The current trend is porting source code to languages that generate native code.

It depends on the workload. ARC can be more expensive than tracing GC, especially with heavily shared objects.

But my main point was that the presence of a GC has nothing to do with how close a language is to the metal. Memory management strategy and low-level capabilities are two separate things.

An absurd amount. The cost wouldn't exceed $500 under a subscription model.

There is no connection. Rust has ARC which performs worse than the tracing GC.