6 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
by ainar-g 2y ago
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.
- vyskocilm 2y agoWell written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.
- galkk 2y agoWow. 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.
- mseepgood 2y agoThey don't have any syntax that differs from the previous Go versions.
- kjksf 2y agoJust 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 agoC#, python - here are the most mainstream examples of syntax that doesn’t look alien.
- valyala 2y agoIterators 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...
- jdnendjjd 2y agoThis argument is brought up again and again, but it is just wrong. Go had both generics and iterators from the get go. Just not user defined ones. Thus it is obvious that the creators of the language always saw their need for a simple and productive language
- eweise 2y agoNot obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.
- joeblubaugh 2y agoI do agree with his point that the implicit mutation of the loop body for an iterative will be difficult to debug.
- valyala 2y agoGo provides generic types since v1.0 - maps, slices and channels. Go also provides generic functions and operators for working with these types - append, copy, clear, delete. This allows writing clear and efficient code. There is close to zero practical need in user-defined generic types and generic functions. Go 1.18 opened Pandora box of unnecessary complexity of Go specification and Go type system because of generics. Users started writing overcomplicated generic code instead of writing simple code solving the given concrete task.
- 2y ago
- everybodyknows 2y agoNomination 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
- maxmcd 2y agoAgreed, 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 agoOne 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
- trustno2 2y agoThe 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).
- yencabulator 2y agoPlenty of people in the community considered dep way too messy to be the real solution.
- nasretdinov 2y agoIterators definitely have one of the strangest syntaxes I've seen, but if you promise not to break the language you better not introduce new syntax without a Major reason (like generics, but even those actually introduced next to no new syntax, even re-using interfaces o_O).
- 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...
- p1necone 2y agoWow, 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.
- skybrian 2y agoI think people do understand the basics of static type systems, but disagree about which types are essential in a "system language" (whatever that is). An integer range is a very basic type, too, conceptually, but many languages don't support them in the type system. You get an unsigned int type if you're lucky.
- edflsafoiewq 2y ago> An integer range is a very basic type, too Not really, its semantics get hairy almost instantly. Eg does it incrementing it produce a new range?
- randomdata 2y agoThe semantics are always complex. The same type of question arises for all basic types. For example, what does adding a string to an integer produce? Or do you give up on answering that and simply prevent adding strings and integers? When one wants to add them they can first manually apply an appropriate type conversion. That is certainly a valid way to address your question – i.e. don't allow incrementing said type. Force converting it to a type that supports incrementing, and then from that the developer can, if they so choose, convert it back to an appropriate range type, including the original range type if suitable. Of course, different languages will have different opinions about what is the "right" answer to these questions.
- sharno 2y agoI’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular
- hu3 2y agoI'm sure of the opposite given the ideas behind Go's design.
- segfaltnh 2y agoIt'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.
- ReleaseCandidat 2y agoJava and C# being the obvious (and more performant) alternatives. And compared to them, Go already wins because of not being, well, "enterprisey". And with that I mean less the languages itself, but also the whole ecosystem around them.
- valenterry 2y agoThere 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.
- tapirl 2y agoDon'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 agoAre there cases where people actually rely on the previous behavior? I always assumed that it was considered faulty to do so.
- rsc 2y agoThere 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 agoLove 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 agoThe 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 agoNo 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.
- paride5745 2y agoI 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.