Not sure I would agree with the community leading aspect. It still feels like Google decides.
My particular point would be versioning. At first Go refused to acknowledge the problem. Then, when there was finally growing community consensus, Go said forget everything else, now we are doing modules.
I also recall the refusal to make montatomicly-increasing-time a public API until cloudflare had a daylight savings time outage.
I think Go's language leadership is one of the worst if not the worst I've ever seen when it comes to managing a language community/PR. Both Ian and Rob come off as dismissive of the community and sometimes outright abrasive in some of the interactions I've seen. Russ Cox seems like a good person, though.
They probably think being hardheaded "protects" the language from feature creep and bad design, but it has also significantly delayed progress (see generics) and generally made me completely turned off from participating in language development or community in any meaningful way, even though I actually like the language. I think there are ways to prevent feature creep and steer the language well without being dismissive or a jerk.
Personally their handling of versioning, generics and ESPECIALLY monotonic time (in all 3 cases, seemingly treating everyone raising concerns about the lack of a good solution as if they were cranks and/or saying fix it yourself) definitely soured me on Go and I would never choose it for a project or choose to work for a company that uses it as language #1 or language #2.
It just left a bad taste in my mouth to see the needs and expertise of actual customers ignored by the Go team that way since the people in charge happened to be deploying in environments (i.e. Google) where those problems weren't 'real' problems
Undeniable that people have built and shipped incredible software with it, though.
> It just left a bad taste in my mouth to see the needs and expertise of actual customers ignored by the Go team that way since the people in charge happened to be deploying in environments (i.e. Google) where those problems weren't 'real' problems
I feel for this, but only to an extent. It's hard to work in any service industry and retain any notion of, "the customer intelligently knows what they want," as a part of your personal beliefs. At the end of the day, you had an idea for a product, and you have to trust your gut on that product's direction, which is going to make some group of people feel a little unheard.
Backend people use Go in my company. They do great things with it. It works well enough when the interface between a Go program and another one is a socket kind of thing.
But we also have a couple system utilities for embedded computers written in Go. I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and set a bunch of environment variables for private repos. Then there is CGO stuff like reading comments as code interfaces. Those things are incredible waste of time of the embedded developers and it makes harder for no reason to onboard people. Go generally spits out cryptic errors when building private repos like those.
I always wanted and still want to create a wrapper that lauches a container, makes whatever "broken" configuration that makes Go compiler happy, figures out file permissions and runs the compiler. The wrapper should be the only go executable in my host system and each repo should come with a config file for it.
> I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and
Just curious.. But why would you disable ssh-based git authentication? It's significantly more convenient when interacting with private repositories than supplying a username and password to https git endpoints.
> set a bunch of environment variables for private repos.
Set up a private Go module proxy. Use something like Athens. The module proxy can handle authentication to your private module repositories itself, then you just add a line in your personal bashrc that specifies your proxy.
In general I don't have complaints with the things you take issue with so I'll digress on those.
> Just curious.. But why would you disable ssh-based git authentication?
I don't disable it. However, not every git repo requires ssh to pull. When working with other languages, if there is a library that I purely depend on, it is perfectly okay to use https only and I use https.
However to use private repos with Golang, one has to modify their global git configuration to reroute all https traffic into ssh because Golang's module system uses only https and the private repos are ssh-authenticated. There is no way to specify which repo is ssh and which repo is https. Last time I used Go, it was at 1.19.
> Set up a private Go module proxy. Use something like Athens. The module proxy can handle authentication to your private module repositories itself, then you just add a line in your personal bashrc that specifies your proxy.
Why should we put more things on our stack just to make a language, which claims to be modern, work? Why do we have to change the global configuration of a build server to make it work? Rust doesn't require this. Heck our Yocto bitbake recipes for C++ can do crazy things with url including automatically fetching the submodules.
Maybe it would make sense to make that change if we used Go everyday but we don't.
> But why would you disable ssh-based git authentication?
Ask the Go developers. AFAIK the only package manager where I have to change my global git configuration to make it work. Even the venerable CPAN and tlmgr behave better.
> Then there is CGO stuff like reading comments as code interfaces.
That's not exactly novel, and while I agree that it's meh what really grinds my gears is the claims / assertions that Go doesn't have pragmas or macros, while they're over there using specially formatted comments as exactly that like it's 2001-era Java.
Anyone who's run an open source project is used to getting feature requests or complaints from groups like:
* people who are merely interested but have no plans to use your project
* people with strong opinions not backed by actual experience
* people with a specific interest (like a new API or feature) who want to integrate it into as many projects as possible
From a naive perspective, it makes sense to treat a request like 'we need monotonic time' as something that doesn't necessarily have any merit. The Go team are very experienced and opinionated, and it seems like it was a request that ran against their own instincts. The design complication probably was distasteful as well.
The problem is, the only reason they never needed monotonic time in the past was that many of them spent all their time working in special environments that didn't need it (Google doesn't do leap seconds). In practice other people shipping software in the wider world do need it, and that's why they were asking for it. Their expertise was loudly disregarded even though the requests came with justification and problem scenarios.
For anyone not familiar with the monotonic time issue, the implementation was found to be incorrect, and the go devs basically closed it and went “just use google smear time like we do lol, not an issue, bye”.
It did eventually get fixed I believe, but it was a shitty way of handling it.
Even the "fix" is... ugh: instead of exposing monotonic time, time.Time contains both a wallclock time and an optional monotonic time, and operations update and use "the right one(s)".
Also it's not that the implementation was incorrect, it's that Go simply didn't provide access to monotonic time in any way. It had that feature internally, just gave no way to access it (hence https://github.com/golang/go/issues/16658).
I mostly loved what they did with with modules/package mgmt. I think SIV was a mistake but modules was miles better then the previous projects even with SIV. Some people seemed to take it very personally that the Go team didn't adopt their prior solution but idk why they expected the go team to use their package manager. I think the SAT style package manager proposed would have created a lot more usability problems for developers and would have been much harder to maintain.
They took it personally because Go led the community and those project leaders on for years that it would be looking, learning, and communicating...
And then dropped the module spec and implementation and mandated it all in about two days. With no warning or feedback rounds or really any listening at all, just "here it is, we're done", out of nowhere.
They have every right to be personally insulted by that.
My particular point would be versioning. At first Go refused to acknowledge the problem. Then, when there was finally growing community consensus, Go said forget everything else, now we are doing modules.
I also recall the refusal to make montatomicly-increasing-time a public API until cloudflare had a daylight savings time outage.