You can cook your own (C++, WASM and Java), but if it was standardized and cross compatible.
Also curious why so many dislike streams?
Golang is basically C with pointers, and still very very static in its programming paradigms.
Were you referring to unsafe pointers and calls to Cgo?
But as far as I understand golang's memory internals, they still offer you to use the copy-based stack directly ("var some SomeStruct;") or to allocate things directly on the heap (via "new(SomeStruct) / make(SomeStruct)".
I might be wrong about this, but this is what I understood from casually reading the spec [1]; while they never mention stack or heap specifically and describe it more as memory being allocated at run time, which kind of hints to a copying garbage collector underneath. But they also seem to implement a mark and sweep mechanism [2] so I'd say it's a hybrid GC, similar to how ECMAScript VMs work these days.
Nevertheless you're right with the argument that it doesn't offer a way to manage memory yourself, which I think is a good thing. Technically you could use "C.malloc()" and "C.free()" though.
> Were you referring to unsafe pointers and calls to Cgo?
Yeah, I was kind of referring to the possibility to implement C-interface adapters using CGO (the internal "C" and "unsafe" packages). Personally I would only use C APIs if there's no way around them, though, and keep as much code in golang as possible.
[1] https://go.dev/ref/spec#Allocation
[2] https://github.com/golang/go/blob/master/src/runtime/mgc.go#...
Those are equivalent calls, you can't explicitly choose to allocate on the stack/heap.
Conceptually there's no distinction between the stack and heap in Go, you just allocate whatever memory you want and the runtime handles cleanup for you.
In practice the compiler will perform escape analysis to place everything it can on the stack, but that's an implementation detail, you don't get to explicitly choose when allocating.
At best you can get the escape analyzer to show what it thinks escapes to the heap and try to coax it to allocate on the stack instead.
It'd be really nice to be able to trigger some scope-exit behavior, too, IMO.
I think I'm not going to like it because I want something that is foundational = works everywhere, is stable everywhere and has all features everywhere (f.ex linux 32-bit on ARM)
But I will give it a fair shoot.
So already plenty of platforms are already covered.
Interested in what you meant by that.