> In Go, most of those objects actually do get allocated directly on the stack, or as fields directly inside other objects.
Most golang code I've seen still relies on pointers to objects, so unless escape analysis is better than say what the JVM or .NET offer, it's not really that different from them. .NET already has value types, and the JVM should be getting them soonish. So there really isn't that much difference from this aspect.
There is a vast difference in this aspect; a []SomeStruct makes two allocations (one for the control structures, one for the data), which might be on the stack or not. Conversely an ArrayList<SomeClass> makes a linear number of allocations; each object in it is separately allocated.
As you say, value types are coming soon, but they don't exist now, so right now there is a lot of difference (and in practice will be for a long time, because not everything is going to migrate to value types immediately).
And even after value types arrive it will be years before library ecosystem leverage that. Typical Java projects use dozens of 3rd party libraries and they are not going to see much effect in next 5 years.
But most of the value of value types would be in your own code to remove boilerplate code. From outside it will for sure be just another class so libraries and frameworks do not need to know abuot your value types.
Most golang code I've seen still relies on pointers to objects, so unless escape analysis is better than say what the JVM or .NET offer, it's not really that different from them. .NET already has value types, and the JVM should be getting them soonish. So there really isn't that much difference from this aspect.