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.
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.
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.
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".
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.
> 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.
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.
> I switched from C++ to C about 7 years ago and never looked back
I'm definitely considering the same, and you're right - it's not C++ itself that appeals to me at all, it's the libraries. I'm not sure what C libraries I'd use for collections (instead of the STL and Abseil [0]), or in lieu of CLI11 [1] or Dear ImGui [2].
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.
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.
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/
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.
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).
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.
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.
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!
