humor: I wonder if the upvotes are cheerings that he finally stepped down or a respectful salute. I give my respectful salute.
Go is awesome and I hope it will continue to progress in that direction. Thank you Russ Cox
Russ Cox is stepping down as the Go tech lead
301–310 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#302Any reference for a website or book that introduce Go for a beginner in depth?
Re: Russ Cox is stepping down as the Go tech lead
#303Thank 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.
Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem. https://research.swtch.com/vgo-intro
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.
Re: Russ Cox is stepping down as the Go tech lead
#304Earlier quoted context omitted.
Dart only found a real good use case fairly recently. Given its explosion in usage since then, I think it may very well be more popular that go in several years.
Curious- what is the use case?
I think they mean Flutter, and Darts truly cross platform abilities.
Re: Russ Cox is stepping down as the Go tech lead
#305IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.
I think this is a side effect of golang having failed at the mission to replace C++ or even Java, becoming a replacement for ruby / python etc for API's. makes the project's goals align with users not about conquering the world anymore. as that battle is lost to Rust, Zig etc.
Go is definitely used for stuff that rivals their Rust/C++ etc. counterparts in terms of performance and general quality.
Caddy and docker pop right into my mind. I‘ve also seen databases, image processing and other nitty gritty systems programming related projects in Go.
People also love to write CLI apps in Go that do a lot of heavy lifting like esbuild or k6 etc.
The sweet spot for Go seems to be IO heavy programs. It allows for just enough control to get good performance for a lot of use cases that bleed into systems programming.
Re: Russ Cox is stepping down as the Go tech lead
#306Earlier quoted context omitted.
Nomination for RSC's greatest technical contribution: module versioning. Absolutely fundamental to the language ecosystem. https://research.swtch.com/vgo-intro
Fundamentally broken model of versioning, but I guess nobody really cares.
Can you elaborate on what problems you have with the MVS algorithm?
Re: Russ Cox is stepping down as the Go tech lead
#307Any reference for a website or book that introduce Go for a beginner in depth?
Re: Russ Cox is stepping down as the Go tech lead
#308Earlier quoted context omitted.
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.
Are there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.
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.
Re: Russ Cox is stepping down as the Go tech lead
#309Earlier quoted context omitted.
False things programmers believe: All reference types should be able to take a null value. It's impossible to write complex and performant programs without null. It's impossible to write complex and performant programs without pointers. References always hold a memory address in a linear address space. (Not even true in C!) Every type is comparable. Every type is printable. Every type should derive from the same comm…
Without pointers in some form or another, you can’t refer to allocated memory. You can change the name of pointers but they are still pointers.
It is possible to write complex and performant programs without allocating memory.
And in some languages, where you only operate on values, and never worry about where something is stored, allocation is just an implementation detail.
Re: Russ Cox is stepping down as the Go tech lead
#310Earlier quoted context omitted.
> Unified codestyle The moment I got my first compile error due to an unused variable and an unused import, made me realize Go is not a serious programming language.
I wonder who hurt them, that is, how much did unused variables/imports hurt at Google for them to make those a compiler error? Insofar I know it, I can imagine C/C++ caused some issues like that because it's hard to figure out whether an import is used, but an unused import does have a cost.
https://research.swtch.com/deps#watch_your_dependencies
> Creeping dependencies can also affect the size of your project. During the development of Google’s Sawzall—a JIT’ed logs processing language—the authors discovered at various times that the main interpreter binary contained not just Sawzall’s JIT but also (unused) PostScript, Python, and JavaScript interpreters. Each time, the culprit turned out to be unused dependencies declared by some library Sawzall did depend on, combined with the fact that Google’s build system eliminated any manual effort needed to start using a new dependency.. This kind of error is the reason that the Go language makes importing an unused package a compile-time error.