3 ms·

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 l

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.
- stickupkid 4y ago
  Specifically to the arena, this required integration with the GC, so couldn't be done as an external library. Hence why a language spec was required.
- klodolph 4y ago
  > Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? I'm sorry, I'm not really sure what difference between Buffer and byte[] in Java I'm supposed to care about, except for the details of how these objects are allocated in memory. There is not really any semantic difference between them, as far as I can tell. Maybe I don't understand what you're saying--I'd love for you to clarify the reasons why you think Go developers are, I guess, a little bit dense, or foolish, or whatever negative adjectives you like to apply to people who use Go (you know, rather than talking about the language itself--it's always fun to make fun of people).
_old_dude_ 4y ago
yes, Java/C# GCs (Android included) and Go GC are very different beasts. Go GC does not move objects in memory (mark and sweep) while other GCs (mark and compact) do, to avoid heap fragmentation and better throughput (see generational GCs). One issue with mark and compact GCs is that you can not move the array of bytes during a system call. A ByteBuffer/Memory object, is an object that allocates its byte arrays using malloc, outside of the heap, so the bytes are not moved by the GC.

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.

stickupkid 4y ago
Specifically to the arena, this required integration with the GC, so couldn't be done as an external library. Hence why a language spec was required.
klodolph 4y ago
> Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? I'm sorry, I'm not really sure what difference between Buffer and byte[] in Java I'm supposed to care about, except for the details of how these objects are allocated in memory. There is not really any semantic difference between them, as far as I can tell. Maybe I don't understand what you're saying--I'd love for you to clarify the reasons why you think Go developers are, I guess, a little bit dense, or foolish, or whatever negative adjectives you like to apply to people who use Go (you know, rather than talking about the language itself--it's always fun to make fun of people).

_old_dude_ 4y ago

yes, Java/C# GCs (Android included) and Go GC are very different beasts. Go GC does not move objects in memory (mark and sweep) while other GCs (mark and compact) do, to avoid heap fragmentation and better throughput (see generational GCs). One issue with mark and compact GCs is that you can not move the array of bytes during a system call. A ByteBuffer/Memory object, is an object that allocates its byte arrays using malloc, outside of the heap, so the bytes are not moved by the GC.