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.
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.
Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.
also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.
Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap.
> Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
Thank you, good to know, looks like big pros in favor of rust as lang for my next project.
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