Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

41–50 of 265 posts

Re: Major standard library changes in Go 1.20

#41

Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it?

I mean, it's opt-in. If you really want to crap your pants, in today's Go, you can import C and call malloc and free, then import unsafe and make pointers into the void. The point of memory safe programming languages is NOT that they entirely disallow all unsafe operations, it's that the language has a proper model for memory safety. In Rust, unsafe code needs to be in unsafe blocks. In Go, unsafe code is only possible by importing unsafe or C.

Adding more unsafe tools to Go or Rust do not diminish their safety guarantees. In fact, when Go and Rust add new unsafe features, they generally do so in a fashion that is much more constrained and has better defined edges than traditional methods, so that it's easier to use them correctly and easier to detect misuses. For example, the borrow checker still runs in Rust unsafe blocks; you still have to circumvent the borrow checker even once you're in unsafe. As for this arena package, it seems to have a few safety mechanisms, and hell, I don't even think it's off the table that it could be made entirely memory safe. This is especially true since memory safe does not mean "free of runtime errors", so all that is needed is to be able to detect the error conditions without allowing potentially undefined behavior to occur first.

Programming language experiments like Go's new arena package are good; they allow exploring what you can do to improve old concepts.

Re: Major standard library changes in Go 1.20

#42
post #8

I think arenas could solve a weird need I sometimes have, the ability to say: “from now one this object should have no references” as a debugging tool.

You might be able to use https://pkg.go.dev/runtime#SetFinalizer for that.

Another option is https://pkg.go.dev/lukechampine.com/freeze -- not exactly what you want, but if the object is mutated after freezing, it will panic.

Re: Major standard library changes in Go 1.20

#43

[flagged]

On a lark, I also asked ChatGPT if there were any grammar errors in a paragraph I was working on when I wrote this post. It said there were, and then gave me the “corrected” version… which was the same thing I had already written. I had to diff it just to prove to myself I wasn’t just glazing over some minor comma placement or something. They need to get the hallucination problem under control to make it more useful.

Re: Major standard library changes in Go 1.20

#44
post #29

Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it?

> 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…

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

Re: Major standard library changes in Go 1.20

#45
post #3

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

The only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012. Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded. Bit rot is life.

How many languages go through the first 11 years of life without significant changes? There are lisps, which have no syntax to change, and I guess elixir, which is itself just a syntax for a very mature runtime (BEAM).

Hell, even C underwent pretty major changes from 72 onwards, because every compiler supported entirely different features. Things like void functions and returning structs or unions. Granted, this predated internet distribution of software, so changes overall were perhaps slower within a single implementation, but there were still radical developments happening on a frequent basis.

Re: Major standard library changes in Go 1.20

#46
post #35

[flagged]

The whole purpose of Go is to make building concurrent and scalable programs simple. Which is does achieve.

Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks.

Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to do optimizations with Go to get fast concurrent code. You pretty much get fast programs by default. This is why it is so popular.

Re: Major standard library changes in Go 1.20

#47

Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue. I mean, you should hear the screams from Rust/Go people about how bad C is, and now you're just going to do it?

> Adding manual arena memory management seems like a weird choice for a supposedly memory-safe and GC'd language where this is supposed to be an implementation issue.

Yes, it's because Go's GC is primarily tuned for latency at the cost of (memory allocation) throughput. Furthermore, there are only a few knobs for Go's GC.

If Go's GC is implemented a bit differently and has a few more knobs so that it can be optimized for memory allocation throughput, maybe Go doesn't need an arena library. I don't even know other GC-ed languages that have/need an arena library because their GC is customizable enough.

Re: Major standard library changes in Go 1.20

#49
post #35

[flagged]

In my experience, Go is really great for writing web backends and CLI tools. Go has replaced Python for me for those use cases and I know it has for others too. I think they've thoughtfully evolved the language (generics took several iterations before being accepted). The tooling especially (cross-compilation, golangci-lint, GoReleaser, the VS Code plugin) makes writing and distributing my little Go apps a blast. Much easier than Python/C++ (though I must say the recent pyproject.toml stuff is really helping me package Python when I need to).

Re: Major standard library changes in Go 1.20

#50
post #35

[flagged]

This is a strange take to me. The last thing in the world that I would accuse the Go developers of is being frantic. There have been discussions about generics for a decade. See this post, for example, that goes into a bit of the history: https://go.dev/blog/generics-proposal

Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be useful only for certain very specific use cases (e.g. maybe proto deserialization, where you hang a million tiny objects off a single GC’ed one and can deterministically bound lifetimes).

Post reply on HN