Even factories. Java puts everything on the heap. There's no on the stack object.
Java and go are both pass by value. Java makes it easy, because i know everything is a pointer to a thing. I (unreasonably?) freak out about go because i don't understand when an array backing a slice change. I'm just chalking it up to me being old and dumb. Seems hard to track, but tons of people do it, so the issue must be me.
I meant "ignoring factories" in the sense of "practically you don't new to get an instance out of a factory, but ultimately it does that internally so let's just ignore this as it's just nit-picking".
> I (unreasonably?) freak out about go because i don't understand when an array backing a slice change.
That seems like the simplest one ever: a slice is a super shitty version of an ArrayList[0], so the slice is modified on assignment (direct or via the slice), and can be replaced implicitly on reallocation. Same as the elementData member of an ArrayList.
[0] because the backing buffer can trivially be shared between slices, which is not the case for ArrayList
Sure there is for primitive types, for objects the compiler gets to decide what lands on the stack given escape analysis, until Project Panama finally gets integrated.
Additionally both IBM and Azul JVMs do have extensions for stack allocations.
A nearly free allocation is still more expensive than being able to not allocate at all, and the nearly free allocation will also add to the GC's workload.
Java and go are both pass by value. Java makes it easy, because i know everything is a pointer to a thing. I (unreasonably?) freak out about go because i don't understand when an array backing a slice change. I'm just chalking it up to me being old and dumb. Seems hard to track, but tons of people do it, so the issue must be me.