Two big issues in Golang are that you can't actually build an arena allocator that can be used for multiple types in a natural way.

The other is that almost no library is written in such a way that buffer re-use is possible (looking at you, typical kafka clients that throw off a buffer of garbage per message and protobuf). The latter could be fixed if people paid more attention to returning buffers to the caller.

▲

bilbo-b-baggins 3 days ago | parent | next [-]

You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.

▲

9rx 3 days ago | parent | next [-]

With a number of caveats. You cannot reimplement arenas as the experiment did without special hooks into the runtime. https://github.com/golang/go/blob/master/src/arena/arena.go

	▲	trhway 3 days ago \| parent [-]
		The special hooks for context and arena (actually arena(s) can be part of context) should have eliminated the need to change signatures for threading context and arena handles through the chain of calls. Instead there should have been an API (both - internal and user accessible) to check and pick, if present, the closest one on stack (somewhat similar to how you can get ClassLoader and the hierarchy of them in Java)

▲

foobiekr 2 days ago | parent | prev [-]

I have done the same; it's not natural to do it this way. Go should actually express an explicit mechanism to do this. When I did it, it felt exactly like trying to use epoll from Go: you can do it, it just feels like crap.

▲

fpoling 3 days ago | parent | prev [-]

Rust also suffers from libraries returning a newly allocated strings and vectors when the code should allow to pass a pre-existing string or vector to place the results.

Granted the latter leads to more verbose code and chaining of several calls is no longer possible.

But I am puzzled that even performance-oriented libraries both in Go and Rust still prefer to allocate the results themselves.