10 ms·

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, gen

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.

tapirl 2y ago
Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html 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.
- dgb23 2y ago
  Are there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.
  - rsc 2y ago
    There were certainly buggy tests that relied on the old behavior. We didn't find any actual code that relied _correctly_ on the old behavior. https://go.dev/wiki/LoopvarExperiment https://go.dev/wiki/LoopvarExperiment
    - dgb23 2y ago
      Love it, even though it must have been incredibly confusing when old tests failed at first. The assumption being that the tests were correct. They _passed_ all those months or years! I'm just also watching your YT video on testing and enjoying it very much!
      - tapirl 2y ago
        The tests are in the simplest forms, there are more complex use cases of traditional "for" loops. The complex cases are never explored by the authors of the change. And there are a large quantity of private Go code in the world.
  - tapirl 2y ago
    No convincing evidences to prove there are not such cases. In my honest opinion, if there are such cases in theory, there will be ones in practice. It is a bad expectation to hope such cases never happen in practice. The authors of the change did try to prove such cases don't happen in practice, but their proving process is totally breaking. It is my prediction that multiple instances of broken cases will be uncovered in coming years, in addition to the new foot-gun issues created by the altered semantics of transitional 'for' loops.
- kiitos 2y ago
  > 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.
  - tapirl 2y ago
    :D It looks you don't understand the change at all. The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me. > You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising. The claim is totally baseless. All my opinions and articles are based on facts. If you have found ones which are incorrect or which are not based on facts, please let me know: https://x.com/zigo_101 https://x.com/zigo_101.
    - kiitos 2y ago
      > The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me. Please provide a link to documentation on golang.org. Note: not a comment in a GitHub issue, not a blog article -- official stuff only. > baseless It should be evident by the consistent responses to your GitHub issues that nobody takes you seriously. Which is unsurprising, when you make recommendations like > Anyway, since Go 1.22, you should try to specify a Go language version for every Go source file, in any of the above introduced ways, to avoid compiler version dependent behaviors. This is the minimum standard to be a professional Go programmer in the Go 1.22+ era.
      - tapirl 2y ago
        I think it is best to let rsc answer your questions. :D
paride5745 2y ago
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.
vyskocilm 2y ago
Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.
- galkk 2y ago
  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.
  - kjksf 2y ago
    Just last week I've implemented an iterator for my C++ type and lol to your comment. It was fucking nightmare compared to how you (will) implement an iterator in Go. I didn't study the reason why Go chose this way over others. I do know they've considered other ways of doing it and concluded this one is best, based on complex criteria. People who make value judgements like this typically ignore those complex consideration, of which playing well with all the past Go design decisions is the most important. Frankly, you didn't even bother to say which language does it better or provide a concrete example of the supposedly non-ugly alternative.
    - galkk 2y ago
      C#, python - here are the most mainstream examples of syntax that doesn’t look alien.
  - mseepgood 2y ago
    They don't have any syntax that differs from the previous Go versions.
- valyala 2y ago
  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-7dfda8a1a620 https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...
everybodyknows 2y ago
Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem. https://research.swtch.com/vgo-intro https://research.swtch.com/vgo-intro
- deleted 2y ago
  [deleted]
- kiitos 2y ago
  Fundamentally broken model of versioning, but I guess nobody really cares.
  - jeremyloy_wt 2y ago
    Can you elaborate on what problems you have with the MVS algorithm?
- nvarsj 2y ago
  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.
- maxmcd 2y ago
  Agreed, see the index of those posts: https://research.swtch.com/vgo 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/regexp1.html - https://swtch.com/~rsc/regexp/regexp4.html https://swtch.com/~rsc/regexp/regexp4.html - https://research.swtch.com/bisect https://research.swtch.com/bisect - https://research.swtch.com/zip https://research.swtch.com/zip
- agumonkey 2y ago
  One I enjoyed a lot (a lot) was this one https://research.swtch.com/pcdata https://research.swtch.com/pcdata Hope he gives us more in the future thanks rsc
LudwigNagasena 2y ago
> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El8FKhmPQJ https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
- yencabulator 2y ago
  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.
  - unscaled 2y ago
    The responses from Ian and the Go fans are not very well-thought. To begin with, zero values were never a great idea. It sounds better than what C does (undefined behavior), but zero values can also hide subtle bugs. The correct approach is to force values to always be initialized on declaration or make use-before-initialization an error. Having said that, it was probably too late to fix zero values by 2009, when Go was released to the public, and this is not what the thread's OP suggested. He referred to Eiffel, which is an old language from the 1990s (at least?) that didn't initially have null-safety (or "void-safety" in Eiffel's case), but released a mechanism to do just that in 2009, shortly after Tony Hoare's talk at QCon London 2009 (no idea if they were influenced by the talk, but they did mention the "Billion Dollar Mistake" in the release notes). Eiffel's added nullability and non-nullability markers to types (called "detachable" and "attached"), but it's also using flow-sensitive typing[1] to prevent null-dereferencing (which is the main cause for bugs). The thread OP didn't ask to eliminate zero values or nullable types, but rather requested to have a non-nullable pointer type, and flow-sensitive typing. If structs need to be zero-initialized, a non-nullable pointer could be forbidden in structs, or alternatively Go could make explicit initialization mandatory for structs that have non-nullable pointers. At the very least, Go could support non-nullable pointers as local stack values, and use flow-sensitive typing to prevent null dereference. [1] https://en.wikipedia.org/wiki/Flow-sensitive_typing https://en.wikipedia.org/wiki/Flow-sensitive_typing
sharno 2y ago
I’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular
- hu3 2y ago
  I'm sure of the opposite given the ideas behind Go's design.
- segfaltnh 2y ago
  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.
  - valenterry 2y ago
    There are definitely lots, I'm one of them. I use Scala, which is very powerful and imho much nicer language than golang. But the tooling and other support is slow and subpar. But I just can't go back to a brain-dead language(!) like golang because it hurts to program in such languages to me. So I hope that either golang catches up with Scala's features, or that Scala catches up with golangs tooling. And I think there are many similar people like me.
    - valyala 2y ago
      Scala is overcomplicated esoteric programming language. It is great for obfuscation contests. It is awful for production code, since Scala code lacks maintainability, readability and simplicity properties.
      - valenterry 2y ago
        I guess we have different opinions. Maybe you had some bad experiences in the past? Scala 3 is very different from Scala 2 many years ago There are few languages that are safer and easier to maintain, imho. The typesafety is superb.

tapirl 2y ago

Don't forget that the semantic change of traditional 3-clause "for" loops: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html 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.

dgb23 2y ago
Are there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.
- rsc 2y ago
  There were certainly buggy tests that relied on the old behavior. We didn't find any actual code that relied _correctly_ on the old behavior. https://go.dev/wiki/LoopvarExperiment https://go.dev/wiki/LoopvarExperiment
  - dgb23 2y ago
    Love it, even though it must have been incredibly confusing when old tests failed at first. The assumption being that the tests were correct. They _passed_ all those months or years! I'm just also watching your YT video on testing and enjoying it very much!
    - tapirl 2y ago
      The tests are in the simplest forms, there are more complex use cases of traditional "for" loops. The complex cases are never explored by the authors of the change. And there are a large quantity of private Go code in the world.
- tapirl 2y ago
  No convincing evidences to prove there are not such cases. In my honest opinion, if there are such cases in theory, there will be ones in practice. It is a bad expectation to hope such cases never happen in practice. The authors of the change did try to prove such cases don't happen in practice, but their proving process is totally breaking. It is my prediction that multiple instances of broken cases will be uncovered in coming years, in addition to the new foot-gun issues created by the altered semantics of transitional 'for' loops.
kiitos 2y ago
> 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.
- tapirl 2y ago
  :D It looks you don't understand the change at all. The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me. > You have a well-documented history of making incorrect claims about Go compiler and runtime behaviors, so this isn't surprising. The claim is totally baseless. All my opinions and articles are based on facts. If you have found ones which are incorrect or which are not based on facts, please let me know: https://x.com/zigo_101 https://x.com/zigo_101.
  - kiitos 2y ago
    > The statement "since Go 1.22, you should try to specify a Go language version for every Go source file" is made officially, not by me. Please provide a link to documentation on golang.org. Note: not a comment in a GitHub issue, not a blog article -- official stuff only. > baseless It should be evident by the consistent responses to your GitHub issues that nobody takes you seriously. Which is unsurprising, when you make recommendations like > Anyway, since Go 1.22, you should try to specify a Go language version for every Go source file, in any of the above introduced ways, to avoid compiler version dependent behaviors. This is the minimum standard to be a professional Go programmer in the Go 1.22+ era.
    - tapirl 2y ago
      I think it is best to let rsc answer your questions. :D

paride5745 2y ago

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.

vyskocilm 2y ago

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

galkk 2y ago
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.
- kjksf 2y ago
  Just last week I've implemented an iterator for my C++ type and lol to your comment. It was fucking nightmare compared to how you (will) implement an iterator in Go. I didn't study the reason why Go chose this way over others. I do know they've considered other ways of doing it and concluded this one is best, based on complex criteria. People who make value judgements like this typically ignore those complex consideration, of which playing well with all the past Go design decisions is the most important. Frankly, you didn't even bother to say which language does it better or provide a concrete example of the supposedly non-ugly alternative.
  - galkk 2y ago
    C#, python - here are the most mainstream examples of syntax that doesn’t look alien.
- mseepgood 2y ago
  They don't have any syntax that differs from the previous Go versions.
valyala 2y ago
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-7dfda8a1a620 https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...

everybodyknows 2y ago

Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem. https://research.swtch.com/vgo-intro https://research.swtch.com/vgo-intro

deleted 2y ago
[deleted]
kiitos 2y ago
Fundamentally broken model of versioning, but I guess nobody really cares.
- jeremyloy_wt 2y ago
  Can you elaborate on what problems you have with the MVS algorithm?
nvarsj 2y ago
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.
maxmcd 2y ago
Agreed, see the index of those posts: https://research.swtch.com/vgo 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/regexp1.html - https://swtch.com/~rsc/regexp/regexp4.html https://swtch.com/~rsc/regexp/regexp4.html - https://research.swtch.com/bisect https://research.swtch.com/bisect - https://research.swtch.com/zip https://research.swtch.com/zip
agumonkey 2y ago
One I enjoyed a lot (a lot) was this one https://research.swtch.com/pcdata https://research.swtch.com/pcdata Hope he gives us more in the future thanks rsc

LudwigNagasena 2y ago

> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El8FKhmPQJ https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...

yencabulator 2y ago
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.
- unscaled 2y ago
  The responses from Ian and the Go fans are not very well-thought. To begin with, zero values were never a great idea. It sounds better than what C does (undefined behavior), but zero values can also hide subtle bugs. The correct approach is to force values to always be initialized on declaration or make use-before-initialization an error. Having said that, it was probably too late to fix zero values by 2009, when Go was released to the public, and this is not what the thread's OP suggested. He referred to Eiffel, which is an old language from the 1990s (at least?) that didn't initially have null-safety (or "void-safety" in Eiffel's case), but released a mechanism to do just that in 2009, shortly after Tony Hoare's talk at QCon London 2009 (no idea if they were influenced by the talk, but they did mention the "Billion Dollar Mistake" in the release notes). Eiffel's added nullability and non-nullability markers to types (called "detachable" and "attached"), but it's also using flow-sensitive typing[1] to prevent null-dereferencing (which is the main cause for bugs). The thread OP didn't ask to eliminate zero values or nullable types, but rather requested to have a non-nullable pointer type, and flow-sensitive typing. If structs need to be zero-initialized, a non-nullable pointer could be forbidden in structs, or alternatively Go could make explicit initialization mandatory for structs that have non-nullable pointers. At the very least, Go could support non-nullable pointers as local stack values, and use flow-sensitive typing to prevent null dereference. [1] https://en.wikipedia.org/wiki/Flow-sensitive_typing https://en.wikipedia.org/wiki/Flow-sensitive_typing

sharno 2y ago

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

hu3 2y ago
I'm sure of the opposite given the ideas behind Go's design.
segfaltnh 2y ago
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.
- valenterry 2y ago
  There are definitely lots, I'm one of them. I use Scala, which is very powerful and imho much nicer language than golang. But the tooling and other support is slow and subpar. But I just can't go back to a brain-dead language(!) like golang because it hurts to program in such languages to me. So I hope that either golang catches up with Scala's features, or that Scala catches up with golangs tooling. And I think there are many similar people like me.
  - valyala 2y ago
    Scala is overcomplicated esoteric programming language. It is great for obfuscation contests. It is awful for production code, since Scala code lacks maintainability, readability and simplicity properties.
    - valenterry 2y ago
      I guess we have different opinions. Maybe you had some bad experiences in the past? Scala 3 is very different from Scala 2 many years ago There are few languages that are safer and easier to maintain, imho. The typesafety is superb.