[ainar-g]

Thank you, rsc, for all your work. Development in Go has become much more enjoyable in these 12 years: race detector, standardized error wrapping, modules, generics, toolchain updates, and so on. And while there are still things to be desired (sum types, better enum/range types, immutability, and non-nilness in my personal wishlist), Go is still the most enjoyable ecosystem I've ever developed in.

[everybodyknows]

Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem.

https://research.swtch.com/vgo-intro

[maxmcd]

Agreed, see the index of those posts: https://research.swtch.com/vgo

Other contenders I find myself sharing and re-reading:

- https://swtch.com/~rsc/regexp/regexp1.html

- https://swtch.com/~rsc/regexp/regexp4.html

- https://research.swtch.com/bisect

- https://research.swtch.com/zip

[trustno2]

The interesting thing is - this went pretty much against the community at the time.

At the time, the community seemed to have settled on dep - a different, more npm-like way of locking dependencies.

rsc said "nope this doesn't work" and made his own, better version. And there was some wailing and gnashing of teeth, but also a lot of rejoicing.

That makes me a bit sad that rsc is leaving.

On the other hand, I don't really like the recent iterator changes, so maybe it's all good.

Btw if you reading this rsc, thanks a lot for everything, go really changed my life (for the better).

[agumonkey]

One I enjoyed a lot (a lot) was this one https://research.swtch.com/pcdata

Hope he gives us more in the future

thanks rsc

[kiitos]

Fundamentally broken model of versioning, but I guess nobody really cares.

[nvarsj]

Not really a fan at all. Dep and its predecessors followed kiss principles, were easy to reason about, and had great support for vendoring.

I’ve wasted so much time dealing with “module hell” in go, that I never dealt with in the prior years of go usage. I think it has some major flaws for external (outside Google) usage.

[LudwigNagasena]

> non-nilness

Ah, I still remember this thread:

https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...

[thayne]

Wow, that's painful to read.

Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.

[deergomoo]

> "Go doesn't have nullable types in general. We haven't seen a real desire for them"

Ouch, who were they asking? There are so many problems from even the most simple CRUD apps where "lack of a value" must be modelled, but where the zero-value is a valid value and therefore an unsuitable substitute. This is probably my single biggest pain point with Go.

Using pointers to model nullability, or other "hacks" like using a map where keys may not be set, feel completely at odds with Go's stated goal of high code clarity and its general disdain for trickery.

I know with generics it's now trivially easy to implement your own Optional wrappers, but the fact that it's not part of the language or even the standard library means you're never going to have a universal way of modelling this incredibly basic and common requirement across projects. It also means you're never going to have any compile-time guarantees against not accidentally using an invalid value—though that's also the case with the ubiquitous (value, error) pattern and so is evidently not something the language is concerned with.

[yencabulator]

Everyone just keeps repeating the same old gripe, without bothering to read the responses.

Go needs a null-like thing because the language forces every type to have a zero value. To remove the concept of zero value from Go would be a major change.

[p1necone]

Wow, that discussion is infuriating. I'm shocked that many people on there don't seem to understand the difference between compile time checks and runtime checks, or the very basics of type systems.

[vyskocilm]

Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.

[galkk]

Wow. I haven't followed Go for a while, thanks for that note.

Iterators are very nice addition, even with typical Go fashion of quite ugly syntax.

[valyala]

Iterators and generics go against the original goals of Go - simplicity and productivity. They complicated Go language specification too much without giving back significant benefits. Iterators and generics also encourage writing unnecessarily complicated code, which makes Go less pleasant to work with. I tried explaining this at https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...

[sharno]

I’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular

[segfaltnh]

It's already quite popular. I'm less convinced there's a large pile of people wishing for a fairly high performance garbage collected language that are not using Go because of this. There just aren't many viable alternatives.

[hu3]

I'm sure of the opposite given the ideas behind Go's design.

[foldr]

Perhaps, but other languages that look a lot like Go with these additions (e.g. OCaml) have not gained much popularity, despite getting much more love on forums like HN. It's important to remember that the people expressing strong opinions about sum types on the internet are a tiny and non-representative fraction of working programmers.

[lupire]

Go has nullable types! We want non-nullable types!

[tapirl]

Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

Because of this change, Go 1.22 is actually the first Go version which seriously breaks Go 1 compatibility, even if the Go official doesn't admit the fact.

[kiitos]

> since Go 1.22, every freshly-declared loop variable used in a for loop will be instantiated as a distinctive instance at the start of each iteration. In other words, it is per-iteration scoped now. So the values of the i and v loop variables used in the two new created goroutines are 1 2 and 3 4, respectively. (1+2) + (3+4) gives 10.

I think you are assuming more guarantees than are actually guaranteed.

You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising.

> since Go 1.22, you should try to specify a Go language version for every Go source file

What on Earth?? Absolutely 100% not.

[dgb23]

Are there cases where people actually rely on the previous behavior?

I always assumed that it was considered faulty to do so.

[paride5745]

I wish they would opt for ARC instead of a GC, to have a more deterministic memory objects lifecycle.

Other than that, I agree with your comment.