5 ms·

> now you're just going to do it? "you can’t import it by default", "you probably shouldn’t be using it at all", "experimental arena package", and 'you must op

> now you're just going to do it? "you can’t import it by default", "you probably shouldn’t be using it at all", "experimental arena package", and 'you must opt-in to even be able to use it via an GOEXPERIMENT environment variable' As for screams from Rust/Go people about how bad C is, it said: > This is highly efficient, but also highly dangerous. What if the programmer makes a mistake [...] > > To mitigate the risk of these kinds of bugs, the arena package will deliberately cause a panic if can detect someone reusing memory after it has been freed. and goes on to explain that each arena has its own unique/distinct address space, so that if a pointer to an object still exists and is dereference it will get a memory access fault, causing the Go program to terminate, with an error message specifying that arena as the cause of the problem. Sounds like a pretty reasonable/cautious experiment to me.

lnxg33k1 4y ago
Yeah I think a language is safe or unsafe according to the ecosystem they live in. A project a developer works on is hardly 100% self-developed and depends on library and third party code, so I understand you have experiments you need to enable, but once it starts spreading in libraries, I think the whole safety guarantee just goes out of the window? As a rust student myself, even the unsafe{} block is stupid
- kaba0 4y ago
  Rust’s unsafe is still much safer than your average C code. The borrow checker checks inside unsafe blocks as well, you can just circumvent it through pointers. But the great thing with unsafe blocks is that you get to create a safe API abstraction on top. You manually verify closely the unsafe parts, and if you got that short part right you can use the safe wrapper wherever you want safely.
cormacrelf 4y ago
> and goes on to explain that each arena has its own unique/distinct address space That does not seem to be how it is implemented now. Try the example use-after-free on https://uptrace.dev/blog/posts/go-memory-arena.html https://uptrace.dev/blog/posts/go-memory-arena.html under 'Address Sanitizer'. There is no error at all when you dereference, it silently keeps working as freed pointers often do (until they don't). Maybe they will add the virtual address space thing later. Edit: the issue (https://github.com/golang/go/issues/51317 https://github.com/golang/go/issues/51317) in which that comment was made also has some people referring to the arena being freed "when the runtime gets around to it" rather than immediately. I can't imagine why the virtual address space wouldn't be made poisonous inside the arena.Free method, but it's possible they do do it later. So your pointers maybe do stop working at an indeterminate time. Sounds pretty much like C. I even tried adding a few `runtime.GC()` calls before dereferencing but to no avail, couldn't get it to crash. The Java 20 implementation has no such issues (https://gist.github.com/cormacrelf/8ddd3cc1b086e4ade93c029a98327d86 https://gist.github.com/cormacrelf/8ddd3cc1b086e4ade93c029a9...), partly because there is no API for allocating a generic T in the arena, so all dereferences are through the managed MemorySegment API. It only seems to offer raw memory, which you can use to implement arrays of unboxed C-style structs, which is great for FFI and network buffers etc. This would be a good tradeoff for Go as well, surely.
- klodolph 4y ago
  If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).
  - kaba0 4y ago
    > why you might not want to use byte[] Such as? Java buffers use byte arrays by default as underlying storage.
    - klodolph 4y ago
      https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffe... Look for "Direct vs. non-direct buffers". Some buffers are backed by arrays, some are not. You're basically deciding whether you are okay with a higher cost for I/O or a higher-cost for interacting with the data in the buffer.
      - kaba0 4y ago
        I do know about it, I was trying to find out what difference do the parent mean between Go’s byte arrays and Java’s solution(s). Also, I fail to get your conclusion — direct buffers only have a higher cost for initialization/dealloc otherwise reading/writing should be as cheap as it gets. Byte buffers on the other hand do get write barriers but that is also unlikely to be hit that often (and I believe larger byte arrays get allocated in a separate region that doesn’t get moved).
  - eptcyka 4y ago
    Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? Maybe go only ever needed []byte, and nothing else - it's always just bytes anyway, right? Moreover, when the go team accomplishes the same goals by extending the language instead of using a library, this is well received.

lnxg33k1 4y ago

Yeah I think a language is safe or unsafe according to the ecosystem they live in. A project a developer works on is hardly 100% self-developed and depends on library and third party code, so I understand you have experiments you need to enable, but once it starts spreading in libraries, I think the whole safety guarantee just goes out of the window? As a rust student myself, even the unsafe{} block is stupid

kaba0 4y ago
Rust’s unsafe is still much safer than your average C code. The borrow checker checks inside unsafe blocks as well, you can just circumvent it through pointers. But the great thing with unsafe blocks is that you get to create a safe API abstraction on top. You manually verify closely the unsafe parts, and if you got that short part right you can use the safe wrapper wherever you want safely.

cormacrelf 4y ago

> and goes on to explain that each arena has its own unique/distinct address space That does not seem to be how it is implemented now. Try the example use-after-free on https://uptrace.dev/blog/posts/go-memory-arena.html https://uptrace.dev/blog/posts/go-memory-arena.html under 'Address Sanitizer'. There is no error at all when you dereference, it silently keeps working as freed pointers often do (until they don't). Maybe they will add the virtual address space thing later. Edit: the issue (https://github.com/golang/go/issues/51317 https://github.com/golang/go/issues/51317) in which that comment was made also has some people referring to the arena being freed "when the runtime gets around to it" rather than immediately. I can't imagine why the virtual address space wouldn't be made poisonous inside the arena.Free method, but it's possible they do do it later. So your pointers maybe do stop working at an indeterminate time. Sounds pretty much like C. I even tried adding a few `runtime.GC()` calls before dereferencing but to no avail, couldn't get it to crash. The Java 20 implementation has no such issues (https://gist.github.com/cormacrelf/8ddd3cc1b086e4ade93c029a98327d86 https://gist.github.com/cormacrelf/8ddd3cc1b086e4ade93c029a9...), partly because there is no API for allocating a generic T in the arena, so all dereferences are through the managed MemorySegment API. It only seems to offer raw memory, which you can use to implement arrays of unboxed C-style structs, which is great for FFI and network buffers etc. This would be a good tradeoff for Go as well, surely.

klodolph 4y ago
If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).
- kaba0 4y ago
  > why you might not want to use byte[] Such as? Java buffers use byte arrays by default as underlying storage.
  - klodolph 4y ago
    https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffe... Look for "Direct vs. non-direct buffers". Some buffers are backed by arrays, some are not. You're basically deciding whether you are okay with a higher cost for I/O or a higher-cost for interacting with the data in the buffer.
    - kaba0 4y ago
      I do know about it, I was trying to find out what difference do the parent mean between Go’s byte arrays and Java’s solution(s). Also, I fail to get your conclusion — direct buffers only have a higher cost for initialization/dealloc otherwise reading/writing should be as cheap as it gets. Byte buffers on the other hand do get write barriers but that is also unlikely to be hit that often (and I believe larger byte arrays get allocated in a separate region that doesn’t get moved).
- eptcyka 4y ago
  Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? Maybe go only ever needed []byte, and nothing else - it's always just bytes anyway, right? Moreover, when the go team accomplishes the same goals by extending the language instead of using a library, this is well received.