It’s weird that I can read an article and tell that it was probably generated with an LLM. There are subtle ways that writing is structured along with word usage and argument construction that don’t feel like what a human would write.
LLMs have also ruined the word “genuine” and its derivatives.
I also welcome ranging over ints, and iterators. I think both of them add ease to the language, but ease and simplicity aren’t the same thing.
Too much easy can wind up actually making things harder if we aren’t very careful, so there’s a balance there.
One could argue a distinction based on bounded vs unbounded, but that is the complexity surfacing. It’s not “1 conceptual value, 1 actual value” it’s “1 conceptual value with bounds, 1 actual value and 1 index value; 1 conceptual value without bounds, 1 actual value and no index value”.
But it’s also not like the design of for-range wasn’t complex to begin with. Iterators just made it more complex. Arrays, slices, and strings probably shouldn’t return an index because channels (and now iter.Seq) don’t.
Ah, right! The ,ok syntax doesn’t work for for-range loops because a false there exits the loop.
I do think that if iterators with an arbitrary number of return values were allowed, the consumption side would’ve been minimally complected.
As I mentioned in the episode, the Go team writes very specific kinds of Go code with very specific constraints. Those don’t apply widely to the community. We’d be asking them for guidance in an area where they aren’t the experts.
We should ask those with expertise instead. That’s the community.
The design of packages holds them back quite a bit here. Any attempt at an opinionated “put this code here” declaration is going to be entirely subjective. There’s no enforcement mechanism.
On the internal complexity, while we are now isolated from the complexity, when they were initially developed there was a nasty interaction between LockOSThread and pull style iterators that leaks implementation complexity directly into both producers and consumers. There were a few other leaks too.
Functions don’t fit the paradigm of a rangeable things, so their addition made for range more complex as a result.
The benefit is that they did make things easier. It’s more intuitive for many of us to use an iterator than returning a slice or a channel.
One of the first questions I asked when I started using iterators is “why can I only return one or two values?” All of the other rangeable things return 2 things (except for numbers, which also added complexity).
The complexity in this case comes both from their implementation (the whole coroutines thing) and their use. For example, with for range previously the things provided were conceptually “rangeable” things, eg slice, array, channel, etc… but now we’ve added a special looking function.
I also use the term “complexity” in the way that Rich Hickey defines in Simple Made Easy, instead of the more general but vague understanding (which often conflates it with hard).
Iterators in particular are interesting. I’d say they complected for range loops, but also pull iterators would up being quite difficult to implement (and general coroutines turned out to be far too much work to implement with the current runtime).
I’m not sure if I’d say generics made the language more complex. I think the way they are done fits rather cleanly into the language.
Things like the internal directory, modules, and even iterators did add considerable complexity.
Also really like the article! I’m a fan of types for errors. Fields you can inspect is a huge win over trying to parse information out of a string.
I agree, but I also want us to find our path back to a more vibrant community.
Or at least find our way back to being a community and programming language that questioned whether the complexity we all deal with is essential or accidental. Go seems to have lost the thread on simplicity as of late.
The thing about doing comprehensive research projects is that the results are often shocking at first, then they gain nuance and feel like they have less punch to them, and then you round the corner of finishing up and you sit in awe at how everything just came together.
I’m deep into some research. I keep running new experiments and proposing new hypotheses. With everyone so far I’m like “this can’t possibly be true” and with each one it winds up, somehow, being worse than what I had hypothesized.
“Fix your upload speeds, then we can talk” 😂
Whatchu mean 5Gbps symmetric? Do you even have a 10Gbps network?? 🤨
“I hate complaining about tech”
Oh so we’re just lying on the internet now?
But even if we concede that it's a source of truth, what makes it a stronger one than a centralized registry?
"which acts as a stronger source of truth than a centralized registry"
But it's not a source of truth, it's a cache. This is precisely what the BoltDB vulnerability showed. The source of truth (the source code on GitHub) conflicted with the SumDB and the module proxy.
I see what you're saying, re: resolved versions. If all you want to know are the versions then you should just look at the go.mod file.
I think many of them would purchase something like the Volt though. That "I can just stop at the gas station like I always do" is a comforting thing for a whole lot of people.
I hope for a world where EREVs start taking over. I think there are many good uses for BEVs, but the range anxiety and shift of norm is too much for a lot of people.
So while the go.sum file isn't a lock file explicitly, it does contain the information necessary for a reproducible build, which is one of the reasons why lock files exist.
There's no way to guarantee a reproducible build without a go.sum file.
I do think that MVS if used by another language that had a central repository would do what it claims without needing a lock file.
But in the Go ecosystem, versions cannot be immutable because the source of truth declares them as mutable.
If you're using a single module proxy and the sum database and all of your dependencies are in that module proxy, then there is a case where you'll get a reproducible build. However, for many reasons, not everything is in the main module proxy and not everyone wants to use it.
What v1.2.3 of module example.com points to today might be different than what it points to tomorrow. The go.mod file has no way of knowing this.
With a go.sum file you can at least catch this change.
