gomodjail VS go

The inability to directly modify a value in a map isn't a flaw in Go; it's a deliberate design decision. A look at the Go team's internal discussions (like GitHub Issue #3117) shows they chose predictability and memory safety over a minor syntactic convenience.

> I didn't realize how important order was to type inference.

I was unclear, I'm afraid. You can reorder the type parameters, it just changes which of them you need to specify: https://go.dev/play/p/oDIFl3fZiPl

The point is that you can only leave off elements from the end of the list, to have them automatically inferred.

> Are there any real packages out there using these techniques?

I think so far, the usage of generics for containers in Go is still relatively sparse, in public code. I think in part that is because the documentation of how to do that is relatively sparse. That is part of the motivation for the post, to have a bit of somewhat official documentation for these things, so they become more widely known.

The standard library is just starting to add generic containers: https://github.com/golang/go/issues/69559 And part of that is discussing how we want to do things like this: https://github.com/golang/go/issues/70471

That being said, I have used the pointer receiver thing in my dayjob. One example is protobuf. We have a generic helper to set a protobuf enum from the environment. Because of how the API was designed, that required a pointer receiver constraint.

Source code for sync.Cond.Wait() (Go standard library) https://github.com/golang/go/blob/master/src/sync/cond.go For those who want to go under the hood and see how Wait() really works internally (with runtime_notifyListWait).

> Lack of proper enums is hurting so much I can't describe it.

Do you mean sum types? Its enums function just pretty much like enums in every single other language under the sun. If anything, Go enums are more advanced than most languages, allowing things like bit shifts. But at the heart of it all, it's all just the same. Here are enum implementations in both Go and Rust:

[Go] https://github.com/golang/go/blob/f18d046568496dd331657df4ba...

[Rust] https://github.com/rust-lang/rust/blob/40daf23eeb711dadf140b...

While Go leans on the enumerator value produced by `range`, while Rust performs explicit incrementing, the outcome is no different — just plain [n=0, n++].

This is one of the many things where Go just takes care of automatically. Since Go 1.19, if you import the os package, on startup, the open file soft limit will be raised to the hard limit: https://github.com/golang/go/commit/8427429c592588af8c49522c...

For a deeper dive, check out the source code for sync.Cond.

> But is know that the current way of Go (that is a insignificant improvement over the C way) sucks and ANY of the other ways are truly better […]

This is a bold statement for something so subjective. I'll note that the proposal to leave the status quo as-is is probably one of the most favorably voted Go proposals of all time: https://github.com/golang/go/issues/32825

Go language design is not a popularity contest or democracy (if nothing else because it is not clear who would get a vote). But you won't find any other proposal with thousands of emoji votes, 90% of which are in favor.

I get the criticism and I agree with it to a degree. But boldly stating that criticism as objective and universal is uninformed.

Relevant proposal to make GOMAXPROCS cgroup-aware: https://github.com/golang/go/issues/73193