And it is much more verbose, it is not even comparable in observability and on real world big applications (especially enterprise) you can't get away with value types and slowing down the threads to let the GC keep up with them -- Java definitely shines in these kind of conditions (GC-wise the only competition Java has is different Java GCs, really).
> you can't get away with value types and slowing down the threads to let the GC keep up with them
I am not Go expert, but to me this is Go's big advantage: you can chose you want to have object GC controlled or be on stack and copied everywhere.
GC controlled objects add lots of overhead, because malloc is expensive, and require lots of memory per object to track state and synchronize between thread, and that's why JVM tries to adapt something similar: https://openjdk.org/jeps/8277163
Sure, value types are a good thing, but they are no panacea in and of itself.
Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.
> they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it
yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all.
With value objects you have full control and bare-metal-native performance without compromises.
