[EdSchouten]

The situation around alignment of integers for atomic operations is unfortunate. I think the cause for it is that they need to use a 4-byte alignment of int64 on 32-bit platforms to remain compatible with C when using cgo. Using an 8-byte alignment is also wasteful, considering that 4 bytes are sufficient and 64-bit atomic operations are relatively rare on 32-bit platforms.

One way to fix this would be to add a special language keyword to increase the alignment, but that feature doesn't really carry its own weight in a language like Go. In my opinion, life would be better if the atomic package didn't allow you to apply atomic operations against raw integers, but had its own boxed integer types that were guaranteed to be properly aligned. I implemented exactly this, because I also got bitten by this more often than I would like:

https://pkg.go.dev/github.com/buildbarn/bb-storage/pkg/atomi...

Now I don't need to worry about that problem anymore. It's annoying that the Go developers focus on stability so much, that the standard library hasn't really evolved a lot since 1.0, which seems to be main source of frustration for the author of this blog post.

What I do appreciate about Go is that cross compilation is pretty good, and the runtime environment also works pretty well. Some time ago I wanted to mmap() some file and also deal with page faults properly (e.g., in case of I/O errors, truncations of the file that's mapped). It turns out that Go can do that really well. Sure, you can install a signal handler for SIGSEGV in C and Rust, but the mechanics behind tend to be confusing.