8 ms·

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.
    • 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
          Where would you expect to see this drama unfold if it were private? Nowhere? That'd be incredible opsec. Code review happens in public, not on GitHub but on Gerrit. The main issue tracker is public, on GitHub. Proposals are largely handled on the issue tracker. There are public mailing lists, etc. Surely, there are face to face private meetings. And there are likely also private issue trackers, mailing lists, and etc. And, yes, sometimes, a seemingly arbitrary decision pops up, that was clearly discussed elsewhere. But these comments seem to come from people who never even tried to contribute, or deal with the process. I've done docs fixes as a total newb, had to convince the Windows maintainer to let me fix a Windows issue (that a year later produced flaky tests, which I fixed), made and got a proposal accepted, have a project in the linkname hall-of-shame, which led to another successful proposal to open up APIs (which then failed tests on some platforms, which I fixed). All with little drama, pure engineering.
        • deleted 2y ago
          [deleted]
    • ein0p 2y ago
      That’s unfair. There’s plenty of drama in projects with all sorts of funding situations. Look at eg Rust. Lots of drama and it’s anyone’s guess if the code you wrote a year ago would work today.
      • lkirkwood 2y ago
        > It's anyone's guess if the code you wrote a year ago would work today Is that true? In what sense? I was under the impression the editions took care of that.
        • seeekr 2y ago
          Not true, not sure why GP said that. Been writing Rust for many years and code does not just break on compiler upgrades. Super stable overall, including the wonderfully evolving ecosystem!
    • sangnoir 2y ago
      And yet we've had lots of drama in Linux and Redhat mailing lists, involving people paid to work on the respective projects, and using their work email.
    • 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.
    • Maxatar 2y ago
      Getting paid has nothing to do with drama. Plenty of high paid people get involved in drama and infighting across all walks of life including tech.
      • segfaltnh 2y ago
        Pretty sure Musk gets a decent paycheck, and manages to be involved in plenty of drama.
  • richardwhiuk 2y ago
    I suspect all the drama happens internally.
    • zja 2y ago
      Are there any Go team members that don’t work for Google? It’s a lot easier to remain civil/avoid drama when people know each other personally, and work together at a big company with an HR department.
      • markkrj 2y ago
        Does ex-googler counts? Then Filippo Valsorda...
    • tomcam 2y ago
      One reason I consider it so good
  • sidewndr46 2y ago
    Absolutely inaccurate. Pointer de-reference operator had a breaking change after 1.x
    • arp242 2y ago
      I don't recall this off-hand; which change was that?
    • tweenagedream 2y ago
      I mean they did say almost no breaking changes, depending how much has changed in the language, a small handful of breaking changes in niche use cases may be considered almost none by some. I'm not sure I would say the comment is absolutely inaccurate.
  • vdqtp3 2y ago
    The cost being that they [generally speaking] ignore proposals, pull requests, and new features - even if they are valuable to their users and AREN'T breaking.
    • segfaltnh 2y ago
      Mostly this comes down to recognizing the value of simplicity. I like Rust and Go, but I am infinitely grateful that Go is as minimal as it is. I wouldn't have had as much success ramping my team on Rust.
  • ahci8e 2y ago
    Almost zero drama, yeah. I do remember the dep drama though...
    • justinclift 2y ago
      And the telemetry drama.
  • gunapologist99 2y ago
    Exactly. And it's in writing! The backwards compatibility promise: https://go.dev/doc/go1compat https://go.dev/doc/go1compat
  • Onavo 2y ago
    They are the programming language equivalent of GitHub repos that maintain a low open issue count by closing most issues as "won't fix" or "won't build".
    • lolinder 2y ago
      Yes. And? Programming languages more than almost any other type of project end up swamped with thousands of competing requests to implement mutually incompatible features. Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption.
      • pansa2 2y ago
        > Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption. Unfortunately that’s not at all true - Go is a real outlier here. If it were true, we’d all be writing C instead of C++, Lua instead of Python and ES5 instead of TypeScript.
        • cookiengineer 2y ago
          The choice is yours. Don't blame your choices on other people's opinion that you don't agree with. Everything in life is a tradeoff. If you don't agree with the available languages, make it better. That's the power of open source :)
          • randomdata 2y ago
            > The choice is yours [pansa2]. Who gave him control over what sees widespread adoption?
        • flohofwoe 2y ago
          FWIW I switched from C++ to C about 7 years ago and never looked back (can't quite escape C++ completely though because some important libraries are still written in C++ unfortunately). I vastly prefer TS to JS, Python and Lua though.
  • truncate 2y ago
    Couldn't agree more. Always felt community had trust in the team. Its not the fanciest language, but whatever they push for usually works. In contrast, recently I've had to deal with Swift, and they are often pushing like 10 features, but each of them is full of holes and annoyances. Great respect for doing the boring of keeping it stupid and simple.
  • moogly 2y ago
    > almost zero drama Hm. Wasn't (the lack of) generics pretty drama filled? Especially the way they fought against it for so long.
    • quectophoton 2y ago
      s/fought against it/rejected superficial proposals that were mostly about syntax bikeshedding and didn't include enough research on how the proposal would play along with the rest of the language and ecosystem/
• tomcam 2y ago
  Your question answers itself. It's growing in popularity in every year and has apparently suffered exactly zero scandals or embarrassing gaffes of any kind. Just not fucking up is huge in making any serious enterprise successful and very, very difficult to achieve.
  • treyd 2y ago
    Just from the top of my head there's the Google proxy shenanigans and the telemetry proposal that they backed down from. There may be others I'm not aware of.
    • kjksf 2y ago
      Explain how Google proxy "shenanigans" are any different than "npm proxy shenanigans" or "cargo shenanigans" or "pip shenanigans". It's a service to improve Go ecosystem with anti-spoof security design (which can't be said about those other code download services). telemetry design is actually very thoughtful, limited and reasonable about what and how much data it sends. Motivation for sending the data is clear (improving Go). It's only a scandal for unreasonable people.
• cookiengineer 2y ago
  The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion upstream is better than no opinion downstream. That's why go's toolchain isn't as messed up as npm, yarn, grunt, gulp, webpack, parcel, babel and other parts of the ecosystem that have no conventions and are therefore as a result very expensive to maintain.
  • daghamm 2y ago
    "That's why go's toolchain isn't as messed up as npm, yarn, grunt, ..." And let's be honest, Rust toolchain is pretty messed up too. Want to cross-compile with go? Set the GOOS variable and you are done. On Rust you need to curl-sh rustup, switch to nightly, add new targets, add target to your cargo and cross fingers it works this week.
    • quectophoton 2y ago
      To be fair, with Go it's still painful to work with private repositories. And I'm invoking Cunningham's Law here when I say there's no convenient way to do so. If you want to use a private repository (let's say it's a private GitHub repository), then you either have to do it the bad way (setting up your own GOPROXY and setting it up securely, which implies also ensuring it's not leaking your source code elsewhere for "analytics purposes"), or the worse way (doing brittle text replacement using weird git config stuff). Or the annoying way of using a vanity import, and host that package in your domain with HTTPS using a wildcard certificate. But that would require either (1) only allowing access through WireGuard and hoping whatever reverse proxy you use has a plugin for your DNS registry; or (2) letting your VPS provider terminate DNS (e.g. Hetzner load balancer), but filter by IP address in your VPS firewall settings ensuring your public address (IPV4 /32 or IPV6 /64) is always up-to-date in the firewall. Or using `replace` in `go.mod`, but these don't work transitively so these only work on "root" projects (i.e. they are ignored in dependencies), so I don't think this really counts as a solution. I would have liked some way to force SSH access for a specific package, instead of HTTPS. Like for example `go.mod` supporting a `require-private` to use instead of `require` (or whatever similarly convenient directive for `go.mod` that implies authenticated SSH access is required). Or in other words, say I have a package `github.com/_company/project`, and it depends on `github.com/_company/dependency`. I want to be able to do: git clone 'git@github.com:_company/project.git' 'project' cd 'project' go mod tidy # Should just work. `go mod tidy` should just work without complaining about `github.com/_company/dependency` not existing (because it's a private repository only accessible through SSH). (EDIT: Still, I'm agreeing with the point that Go's tooling is better than most other things I've tried. My only complains are this one about being inconvenient to use private repositories, and also that by default it leaks package names to Google whenever you do `go mod tidy`.)