111–120 of 396 posts
Earlier quoted context omitted.
I suspect all the drama happens internally.
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.
> 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.
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 th…
* Keras
* Ruby
* Clojure
* Zig
* OCaml
* Vim
* Elixir
I think all of these have ended up being unusually coherent. I may not agree with their design philosophy, but there clearly is one.
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.
I’m sure if Go had nullable types and/or sum types from the beginning, it’s have been much more popular
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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".
Earlier quoted context omitted.
Zero drama is easy when you get paid (a lot) to work on something.
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.
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, 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.
Earlier quoted context omitted.
> non-nilness Ah, I still remember this thread: https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
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.
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.
Earlier quoted context omitted.
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.
Only those instances make the news. And then get repeated time and time again. It's a super-biased view not at all representative of his day-to-day behaviour. Also I've never seen Torvalds "chewing out people on mailing lists for something stupid they said", it's always been someone breaking something or something along those lines. That is: doing stupid. And it's also experienced maintainers Torvalds feels should ha…