Major standard library changes in Go 1.20

Re:Major standard library changes in Go 1.20 by klodolph on Tuesday January 17, 2023 @01:22AM (#34409674)

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).

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by kaba0 on Tuesday January 17, 2023 @02:56AM (#34410141)

> why you might not want to use byte[]

Such as? Java buffers use byte arrays by default as underlying storage.

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by klodolph on Tuesday January 17, 2023 @05:49AM (#34411086)

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.

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by kaba0 on Tuesday January 17, 2023 @07:50AM (#34411818)

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).

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by eptcyka on Tuesday January 17, 2023 @03:20AM (#34410281)

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.

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by stickupkid on Tuesday January 17, 2023 @04:58AM (#34410825)

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.

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by klodolph on Tuesday January 17, 2023 @05:44AM (#34411054)

> 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).

[ Parent | on HN ]

Re:Major standard library changes in Go 1.20 by _old_dude_ on Tuesday January 17, 2023 @04:58AM (#34410827)

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.

[ Parent | on HN ]