3 ms·

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

by foobiekr 10mo ago

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.

fpoling 10mo ago
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.
bilbo-b-baggins 10mo ago
You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.
- 9rx 10mo ago
  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 https://github.com/golang/go/blob/master/src/arena/arena.go
  - trhway 10mo ago
    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 10mo ago
  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 10mo ago

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.

bilbo-b-baggins 10mo ago

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

9rx 10mo ago
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 https://github.com/golang/go/blob/master/src/arena/arena.go
- trhway 10mo ago
  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 10mo ago
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.