12 ms·

Russ Cox is stepping down as the Go tech lead

• 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 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.
      • mseepgood 2y ago
        They don't have any syntax that differs from the previous Go versions.
      • 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.
    • 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...
      • jdnendjjd 2y ago
        This 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 ago
          Not 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 ago
          I do agree with his point that the implicit mutation of the loop body for an iterative will be difficult to debug.
        • valyala 2y ago
          Go 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 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
    • 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
    • trustno2 2y ago
      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).
      • yencabulator 2y ago
        Plenty of people in the community considered dep way too messy to be the real solution.
      • nasretdinov 2y ago
        Iterators 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 ago
      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.
      • skybrian 2y ago
        I 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 ago
            The 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 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.
      • ReleaseCandidat 2y ago
        Java 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.
        • pjmlp 2y ago
          Go's is already "enterprisey" enough, thanks to Kubernetes ecosystem.
          • wordofx 2y ago
            For the 3 people who actually need Kubernetes.
      • 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.
  • 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.
  • 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.
• tschellenbach 2y ago
  Thank you, amazing language :)
• throwawaygo 2y ago
  I have so many disagreements on goals for the language with Russ, but have been a fan since his early days of writing the regex package and the c-to-go conversion code. Glad to hear he will still contribute to the lang, and hoping for a bit different direction from the new leads.
• tomcam 2y ago
  IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.
  • hoten 2y ago
    What are some things that make it well managed?
    • ein0p 2y ago
      Almost zero drama and almost no feature creep or breaking changes. The team seems to have a focus, and does not change it easily. That is important for a programming language, and it doesn’t happen organically.
      • dom96 2y ago
        Zero drama is easy when you get paid (a lot) to work on something.
        • goalonetwo 2y ago
          I would rather say that it is easy to have zero drama when most of the committers come from a single large companies.
        • muratsu 2y ago
          Huhhh? Have you ever worked at a large enough company where stakeholder interests are not aligned?
          • IshKebab 2y ago
            That's private drama. For all we know there has been loads, but it's private so you can't see it.
            • ncruces 2y ago
• keybored 2y ago
  [flagged]
  • oneepic 2y ago
    Certain people take their job seriously. You can judge that however you want, but they exist.
  • deleted 2y ago
    [deleted]
• purpleidea 2y ago
  Huge news! I hope the new leadership remembers that keeping golang small and simple was its greatest strength. Adding generics was too much, and while I think there are some important small cases when it's valuable, in practice people are using it when they shouldn't. I'd also like to see less google control of the project. I'm certainly thankful for golang as it made my https://github.com/purpleidea/mgmt/ https://github.com/purpleidea/mgmt/ project possible! Thanks Russ!
  • simonz05 2y ago
    > I'd also like to see less google control of the project. That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.
    • rsc 2y ago
      > Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google. I don't believe this is true at all. They are both highly active in external Go development, far more active than I have been these past few years. (It's true that neither gives talks or blogs as much as I do.)
      • simonz05 2y ago
        I understand and respect your perspective on Austin and Cherry’s involvement in the Go community. Their contributions may indeed be less visible but still impactful. However, the community’s perception of leadership is crucial, and visibility plays a big part in that. For instance your long form blog adds context to decisions you’ve taken in the past. I hope their active roles will become more apparent, fostering a stronger connection with the broader Go community.
  • arp242 2y ago
    > I'd also like to see less google control of the project. What does this even mean? Google basically just finances the project, but doesn't really "control" anything, never mind that "Google" isn't a monolithic entity in the first place.
• rollulus 2y ago
  Since rsc frequents HN: I’d like to thank you for all the work you’ve put into this great language. Peak HN hype cycle I decided to pick up Go and never regretted it. Thank you.
• skywhopper 2y ago
  Russ has done a great job of shepherding Go through over a decade of growth and maturity and has led a ton of fantastic additions to the language and built a strong pattern of excellence in how language changes are considered and made that should serve as a shining example for the future of Go as well as any other language out there. And now he’s continuing the stretch of outstanding leadership by passing the torch. I can wait to see what the next 12 years of Go brings. Thanks for your service, Russ!
• shoggouth 2y ago
  Thanks for working to create such a great language!
• simonz05 2y ago
  https://www.youtube.com/watch?v=wwoWei-GAPo https://www.youtube.com/watch?v=wwoWei-GAPo — Project has come a long way since this. Happy that it's still around and thriving. I don't think we expected that in 2009. I don't believe Go would have been where it is without Russ. His contribution to the project has been tremendous. Thanks Russ.
• meling 2y ago
  Thanks Russ for your great leadership and contributions to the Go community. I’ve always enjoy your talks, blogs, and your many contributions to the language. Looking forward to your future contributions to the language and ecosystem.
• Thaxll 2y ago
  RSC has a really good blog: https://research.swtch.com/ https://research.swtch.com/
  • jjice 2y ago
    Incredible blog. I've said it on this site before, but his series on regular expressions is insanely high quality and the fact he just posted it there for all of us is a huge privilege.
    • mikhailfranco 2y ago
      Yes, I certainly benefitted very much from the series. Here is the first episode - devastating, convincing, easy to understand and very well written: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
  • furyofantares 2y ago
    This is the first time I'm noticing that rsc would be an initialism for the blog.
    • rsc 2y ago
      Me too!
      • furyofantares 2y ago
        :) While you're still reading these, I want to say that while I've never ended up using Go for any shipping projects, I've been a fan since day 1. And it hasn't been lost on me that in the languages and ecosystems I do use in my professional life, good decisions from Go have propagated through the software world. One thing that really sticks in my brain is gofmt; it makes it clear that there's still relatively low-hanging fruit where you can make a really good decision that spreads to the rest of the world on merits alone. It's an inspiration.
• dondraper36 2y ago
  rsc, thank you very much for all the hard work on the language that brought me into software engineering. Despite playing around with several programming languages, Go still feels like home. The development experience is terrific and I really appreciate how unapologetically simple and responsible the language and its creators have been. Good luck and all the best in all your endeavours!
  • rsc 2y ago
    > rsc, thank you very much for all the hard work on the language that brought me into software engineering. You're quite welcome, and thank you for this comment. I never expected when we started that Go would have such a positive impact on people's lives, bringing new people into programming and software engineering. That's definitely the impact I'm most proud of.
    • geoka9 2y ago
      Thank you guys from another fan! Go literally saved my career as a software dev: got burned out around 2014, tried Go as therapy and have been a happy gopher ever since :)
    • captainkrtek 2y ago
      Same sentiment as the above poster. I’ve been working with Go since 2014, after using many languages before, and none match the ease and efficiency of development for my work. Thank you so much!
    • apitman 2y ago
      I've been programming for 20 years and Go has proven to have more gravity than any other language I've used. When I just need to get something done, it's what I reach for. Thank you for your part in building such a useful tool.
    • slekker 2y ago
      Thank you very much rsc! Golang not only helps me feed my family but also I created many friendships from using it :)
• igmor 2y ago
  Go team has built a remarkable tool under your leadership. A tool that moved a niddle to the better side of things for the industry. Thank you and God speed!
• septune 2y ago
  Thanks Russ and infinite kudos to you
• mseepgood 2y ago
  Please make more Ivy videos
  • remus 2y ago
    I think you might be thinking of Rob Pike's project, unless Russ has been involved? https://github.com/robpike/ivy https://github.com/robpike/ivy
    • bear8642 2y ago
      Russ has indeed been involved, he's done various videos solving advent of code using Ivy. Russ has also got a pull request to add an operator, see https://github.com/robpike/ivy/pull/83 https://github.com/robpike/ivy/pull/83
    • rsc 2y ago
      https://www.youtube.com/watch?v=ek1yjc9sSag&list=PLrwpzH1_9ufMLOB6BAdzO08Qx-9jHGfGg https://www.youtube.com/watch?v=ek1yjc9sSag&list=PLrwpzH1_9u... I don't intend to make more of those, but that was a lot of fun.
    • deleted 2y ago
      [deleted]
• xyst 2y ago
  I think the only reason I used go at some point was because of Russ Cox. Have joined the dark side and switched to rust ;). Wonder what he’s going to do next? Maybe just moving around within G? or another OSS project within G?
  • dochtman 2y ago
    The post actually contains some references to what he’s working on next, some kind of LLM agent to facilitate software development processes?
• nasretdinov 2y ago
  Russ gave us proper vendoring and generics: two things I thought I'd never see in Go... Thanks a lot for the effort!
  • bruckie 2y ago
    Ian Lance Taylor did a lot of the work on generics, too. Thanks to both, and the rest of the team!
  • valyala 2y ago
    While vendoring is great, generics is bad addition to Go, since they complicated Go type system too much [1]. This makes typical Go code with generics hard to read and hard to maintain. [1] https://go.dev/blog/type-inference https://go.dev/blog/type-inference
    • conjurernix 2y ago
      Language was literally castrated without generics.
      • valyala 2y ago
        Lack of generics didn't prevent from creating many useful projects in Go such as Docker, Kubernetes, Prometheus, Terraform, etcd, minio, Caddy, Traefik, and many others from the list at https://github.com/search?q=language%3Ago+stars%3A%3E10000&type=repositories https://github.com/search?q=language%3Ago+stars%3A%3E10000&t... . I haven't heard of useful Go projects, which couldn't be written because of lack of generics before Go1.18, and which have been created after that. Also I'm unaware of useful projects, which benefitted from generics in any measurable way.
• hgyjnbdet 2y ago
  Out of interest, why are people so confident in Google when it comes to Go, yet every other day there's articles about how Google can't be trusted in related to Dart/Flutter which are soon to be abandoned?
  • bufo 2y ago
    Because Go has massive traction both inside and outside of Google, whereas Dart/Flutter never got big traction.
    • surajrmal 2y ago
      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.
      • smithcoin 2y ago
        Curious- what is the use case?
        • hgyjnbdet 2y ago
          I think they mean Flutter, and Darts truly cross platform abilities.
  • nu11ptr 2y ago
    > Google can't be trusted in related to Dart/Flutter which are soon to be abandoned source?
    • hgyjnbdet 2y ago
      I'm not agreeing with that assessment but recently: https://news.ycombinator.com/item?id=40997745 https://news.ycombinator.com/item?id=40997745 https://news.ycombinator.com/item?id=40184763 https://news.ycombinator.com/item?id=40184763 Among others. Again I'm not saying I agree, I'm just saying you don't see the same with Go.
• declan_roberts 2y ago
  There are features of the Go toolchain that I consider to be a requirement in all future languages. For example, if a language doesn't come with a built-in formatter that's a huge red flag. Go broke the tyranny of style discussions. Easy static binaries is right up there for all new languages. Kudos to rsc and team for all the work that went into making a great language. Good luck on your next projects.
  • deleted 2y ago
    [deleted]
• alphazard 2y ago
  > I don’t believe that the “BDFL” (benevolent dictator for life) model is healthy for a person or a project It's interesting that the best projects have BDFLs, and that the best BDFLs are skeptical of their own power.
  • groby_b 2y ago
    The only people worth having in power are the ones that don't want the power. This extends well beyond OSS projects.
  • darby_nine 2y ago
    I don't think this is true. Python had a BDFL and it didn't seem to benefit much from it. I'm not sure what other projects this attitude draws from. Off-hand I'd guess it causes less drama but no appreciable increase of quality, just like other forms of bureaucracy. Meanwhile there's entire landfills of failed projects with single owners who couldn't bend enough. We just don't find this worth discussing. Of course this won't happen, but a man can dream.
    • vbezhenar 2y ago
      Python became #1 language in the world. Which factors lead to this success is debatable, but leadership role can't be dismissed.
    • anamexis 2y ago
      Linux/Linus Torvalds stands out as another notable BDFL.
      • gunapologist99 2y ago
        And Daniel Robbins at Gentoo, who recently (and sadly) stepped down from Funtoo as well.
      • darby_nine 2y ago
        I'm not intimate with Linux as a project, but this is an attractive argument for it. Unfortunately my main experiences with Torvalds are motivated by his chewing out people on mailing lists for something stupid they said rather than fending off varied interests, which makes him look far more petty than competent.
• zmj 2y ago
  Thanks Russ! Putting tooling on a first-class basis was revolutionary, and it's still Go's standout feature.
• coolThingsFirst 2y ago
  [flagged]
• klartd 2y ago
  Thanks for all the Go contributions! I disagree on one point that has nothing to do with Go. Python has not benefitted from GvR stepping down. The new "leadership" is non-technical, tyrannical and has driven almost all true open source contributors away. Development has stalled except for the few corporate contributions of doubtful quality. The atmosphere is repressive and all that matters is whether you have a position of power at Microsoft/Instagram/Bloomberg. It is not necessarily the fault of these companies. They may not know that their generosity is being abused.
  • the_duke 2y ago
    > Development has stalled except for the few corporate contributions of doubtful quality. Do you have some data to back that up? The stats on Github seem to show healthy activity. 700+ merged PRs from 120+ contributors in the last month [1]. There seems to have been a big influx of new contributors in the last few years. [2] [1] https://github.com/python/cpython/pulse/monthly https://github.com/python/cpython/pulse/monthly [2] https://github.com/python/cpython/graphs/contributors https://github.com/python/cpython/graphs/contributors
• DLA 2y ago
  Russ thank you so very much for your outstanding leadership, dedication, design wisdom, and technical contributions to Go. This language, its libraries and tools, and especially the Go community are incredible. You are a class act sir!
• 999900000999 2y ago
  Thank you. Golang is easily one of my favorite new languages. It's fast and clean without the difficulty of Rust. I was able to create a small mobile app with Chat GPT without any real experience in Golang. I would like better mobile and gaming frameworks though. Although I really like Flutter, I think Google missed a major opportunity to use Golang instead of Dart. What's next? Any good for native Chrome support?
  • fuzztester 2y ago
    >I was able to create a small mobile app with Chat GPT without any real experience in Golang. >I would like better mobile and gaming frameworks though er, try asking chatgpt to create them for you.
  • deleted 2y ago
    [deleted]
  • 38 2y ago
    > I was able to create a small mobile app with Chat GPT without any real experience in Golang. so you didn't really create it then did you? ChatGpt created it for you.
    • 999900000999 2y ago
      I'm shameless when using Chat GPT to assist with personal projects. It's just another tool.
      • 38 2y ago
        [flagged]
        • 999900000999 2y ago
          I'll put it this way, the same doesn't apply with Rust. I don't feel ashamed that I didn't manually come up with sorting algorithms. I was able to make a small Golang project and I had fun.
• wejick 2y ago
  Thanks RSC, since the past 8 years I really enjoyed working with Go. It's my first experience following a programming language development, all the proposals, debates and how all of them were handled.
• amiga386 2y ago
  thanksStr := "thank you rsc" ret, err := sayThanks(thanksStr) if err != nil { return nil, err } return ret, nil
  • cocok 2y ago
    Can anyone familiar with Go explain why not return sayThanks(thanksStr) I've seen this "if err != nil" pattern before, but I can't help thinking that it's not necessary. "return ret, nil" ignores err's value, which is nil anyway. "return nil, err" ignores ret's value, but why? If the caller checks for err before doing anything with ret, it doesn't hurt having ret always passed up. 4 extra lines only to lose the value of ret in case of error.
    • tptacek 2y ago
      You can golf it down to return sayThanks("thank you rsc") without losing anything, but then it could just as easily be JS.
    • denysvitali 2y ago
      In this case, the if err != nil is completely useless. Usually the pattern is used to perform better error handling (wrapping errors) or in case you call multiple functions that might return an error. In this case, your suggestion is actually what I would expect to see
    • randomdata 2y ago
      It's a joke about how every contrived Go example posted to the internet is in that vein. You wouldn't blindly pass something up the stack like that in a real application. Well, maybe if you hate other developers for some reason.
    • amiga386 2y ago
      It's not needed if it's just on its own, but Go's error handling makes it necessary when chaining functions, which is why you see it so often. Imagine in Java or Python or C# or ... many languages that use exceptions to handle errors: return a(b(c(arg))); ...where a(), b(), and c() can throw some kind of exception, so you don't have to handle them then and there. In Go there aren't exceptions, all error handling is explicit and handled conventionally by returning an error as the last (sometimes only) return value, which isn't composable, so you get: cVal, err := c(arg) if err != nil { return nil, err } bVal, err := b(cVal) if err != nil { return nil, err } return a(bVal) // the final call can be simpler That's the minimum verbosity required. Since Go 1.13 (2019), they officially added the concept of "wrapped" errors (aka "cause" in languages with exceptions) so instead of returning err you can return errors.Wrap("error in the a-b-c function calling c", err). But nonetheless, _every_ level of the call chain has to wrap or pass on all errors with explicit code. Go does have panic() and recover() which allow for exception-like error handling but it's not idiomatic to use them for normal error handling, go wants that to be explicit. As for why "return nil, err" rather than "return ret, err"? Because while the caller _should_ check for errors, sometimes they just don't. ret, _ := abc(arg) // just ignore the error ret.DoSomethingFun() You as callee don't want to get the blame if you've _partially_ filled an struct because you returned early with an error, and it's then usable but causes a crash because it was partially initalised, because someone ignored the error they got when creating it. That hides where the problem really was. Better to return an empty value, default value or nil.
• j2kun 2y ago
  TIL about the project he's going to focus on: https://go.googlesource.com/oscar/+/refs/heads/master/README.md https://go.googlesource.com/oscar/+/refs/heads/master/README... An LLM-based architecture for helping maintain OSS projects. Seems cool.
• hu3 2y ago
  Go changed the way I think about concurrency. Being able to use channels in a modern programming language is such a gift. rsc thank you for all your contribution to our field. You blog posts also taught me a lot.
• iJohnDoe 2y ago
  Want to say thanks to anyone and everyone that made Go happen. It’s been my language for a while now and I appreciate what it has made available to me.
• rtpg 2y ago
  gofmt probably has alone saved so much time across the world (and is upstream from every other language ecosystem basically saying "ok let's just autoformat"). I hate what autoformatters do to my code, but I love not having to talk about spacing anymore.
  • rob74 2y ago
    Interestingly enough, I hate autoformatters (and use spaces instead of tabs) in every other language, but in Go you just get used to the way gofmt formats your code from the beginning, and then start to appreciate that you don't spend as much time on it anymore, so it's not a problem (at least for most people).
    • arp242 2y ago
      I've seen a number of autoformats for other languages be way too obsessive about formatting every little detail and edge case, to the point where it just becomes silly. 100% consistency is a fool's errand, and also contributes very very little Once you deal with some major issues (braces, spacing) you very quickly get diminishing returns.
      • rtpg 2y ago
        One thing that I've found works kinda well: if you use a linter with "autofix" options, then the policy can be: complaint about formatting? Add the lint that can be autofixed. Then your formatter is just "run the lint autofixes"
• lagniappe 2y ago
  F
• MaiVa 2y ago
  The Go community is incredibly lucky having had a person as lead with such outstanding technical skills and at the same time a great sense of strategic long term view. As this was not enough, I remember reading some discussions where I thought "Damn, this rsc guy has a lot of patience." Go evolves slowly but steadily. No drama, no politics (external, I don't know about the internal), not social justice wars, just great technical and community work focussing on the thing at hand: A programming language and ecosystem.
• jgowdy 2y ago
  Is the new tech lead more likely to get rid of the glibc-isms that Golang won't let go of, like crashing if non-ELF standard parameters like env aren't passed in ELF library initialization, or maybe supporting global-dynamic thread local storage so we can dlopen() shared objects made in Go on platforms that don't hack like glibc? Go's obsession with glibc-isms is really unfortunate, and it's been many years. If you're using Go with containers on Alpine/musl, keep your code very vanilla, because they won't support you.
  • jgowdy 2y ago
    [flagged]
  • liveoneggs 2y ago
    golang's priority is "works inside of google" and everything else tends to be a bit of a fight
    • rsc 2y ago
      This is definitely not true. "Inside of Google" would have been just linux/amd64 for a very long time. Now it includes linux/arm64 too, but that port happened before Google needed it. And all the other ports are not used inside of Google, except maybe the Mac port if you count developers laptops.
      • liveoneggs 2y ago
        https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914
  • jgowdy 2y ago
    Here are some citations since people seem to be just downvoting because they don't like the message: Go requiring non-ELF standard parameters for initialization of supposedly "C ABI" libraries, open since 2015. https://github.com/golang/go/issues/13492 https://github.com/golang/go/issues/13492 The Go project specifically acknowledging the glibc-isms here: "All Linux first class ports are for systems using glibc only. Linux systems using other C libraries are not fully supported and are not treated as first class." https://go.dev/wiki/PortingPolicy https://go.dev/wiki/PortingPolicy Go only supporting static-init thread local storage, and thus their "C ABI" libraries can only be dlopen()'ed if the libc pre-allocates memory to hack in libraries later. https://github.com/golang/go/issues/54805 https://github.com/golang/go/issues/54805
• hankman86 2y ago
  Does Google actually consider Go to be a success? I get the impression that it failed in what it set out to be: a successor to C/C++. Or put differently, Rust has eaten Go‘s lunch.
  • jeffrallen 2y ago
    A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up. It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who need type safety and performance. Someone with no Go experience could land a useful new feature in a big Go program in 3 months. Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go. Which means to me that if Rust had been aiming at this same adoption goal (it wasn't) it would not have succeeded where Go did.
    • zozbot234 2y ago
      > Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go. Do you really think large Golang codebases are so easy to survey? I could see the argument wrt. C++, but Rust actually has a great featureset for programming "in the large". Take a look at the k8s codebase for an example of a large project that's written in Golang - doesn't seem all that easy to get started with.
    • weinzierl 2y ago
      > "Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go." A recent study done at Google disagrees with this assessment. ""it takes about the same sized team about the same time to build it, so that's no loss of productivity", said Google's Director of Engineering Lars Bergstrom about porting Go to Rust in the talk https://youtu.be/6mZRWFQRvmw?t=27012 https://youtu.be/6mZRWFQRvmw?t=27012
• denysvitali 2y ago
  Thank you for all your work Russ!
• philosopher1234 2y ago
  Boy, this makes me sad. He’s really changed my life, I’ve learned so much about software and programming from his writing and thinking. I wish it didn’t have to happen, but I guess it’s only ever a matter of time.
  • rsc 2y ago
    Happy to hear that. Still going to write and think. :-)
• calini 2y ago
  Thank you for making my career more enjoyable and productive, rsc! Go is a lovely ecosystem and I'm looking forward to see where it will Go :).
• deleted 2y ago
  [deleted]
• chmike 2y ago
  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
• zakki 2y ago
  Any reference for a website or book that introduce Go for a beginner in depth?
  • jeremyloy_wt 2y ago
    https://go.dev/tour/welcome/1 https://go.dev/tour/welcome/1
• shynome 2y ago
  [dead]
• fliter 2y ago
  Go has become a very mainstream language, giving software development a new look. Thanks for your leadership of the Go team over the past 12 years, and for your patient comments and guidance on our proposals and PRs. Best wishes for the future, and hope to see you in the community again.