> 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've noticed: competent people who aren't interested in leadership tend to make the best leaders. As compared to people who want to be leaders, for the sake of being known as a 'leader', but have neither the competency nor accountability to be leaders.
Russ Cox is stepping down as the Go tech lead
271–280 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#272Earlier quoted context omitted.
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…
> it's always been someone breaking something or something along those lines Not only is this a complete lie, but God forbid there's a process in place to catch these things instead of verbally abusing your coworkers for making mistakes, which Linus has done himself. > Imagine every outburst you have is public and pointed to for years to come You may be surprised to learn that the rest of us don't talk to anyone like…
The moral superiority is misplaced:
https://news.ycombinator.com/item?id=41017195
But I am not surprised. CoC proponents universally do the same as the people they criticize. Only the application of rules is selective.
Re: Russ Cox is stepping down as the Go tech lead
#273Earlier quoted context omitted.
Wow, that's painful to read. Separating the concept of pointers and nullable types is one of the things that I think go having from the beginning would have made it a much better language. Generics and sum types are a couple of others.
False things programmers believe: All reference types should be able to take a null value. It's impossible to write complex and performant programs without null. It's impossible to write complex and performant programs without pointers. References always hold a memory address in a linear address space. (Not even true in C!) Every type is comparable. Every type is printable. Every type should derive from the same comm…
Well, I'd rather not copy around a multi-hundred-megabyte (or gigabyte) 3D object around to be able to poke its parts at will.
I'll also rather not copy its parts millions of times a second.
While not having pointers doesn't make impossible, it makes writing certain kinds of problems hard and cumbersome.
Even programming languages which do not have pointers (cough Java cough), carry pointers transparently prevent copying and performance hits.
Re: Russ Cox is stepping down as the Go tech lead
#274Earlier quoted context omitted.
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-7dfda8a1...
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
Re: Russ Cox is stepping down as the Go tech lead
#275Earlier quoted context omitted.
What are some things that make it well managed?
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 up…
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.
Re: Russ Cox is stepping down as the Go tech lead
#276Earlier quoted context omitted.
I think the fundamental reason behind this behavior is just Go's rejection of the concept of compiler warnings. Unused variables must either be A-ok or trigger an error. They chose the second option for unused variables. Some other code smells are considered A-ok by the compiler and need to be caught by linters.
The problem with such rejection is that every serious project written in Go has invented compiler warnings outside the compiler, with linters.
`go vet` is part of Go toolchain so the designers very much understand and acknowledge that code can have issues that are not always errors.
The distinction they made is very simple: an error is something that is always wrong and a vet warnings is something that is possibly wrong but not always.
They made a judgement call to split the responsibility: compiler only reports errors, other tools, including `go vet`, can tell you about other issues.
For example: passing a large struct by value to a function is potentially a performance problem but it's also correct code.
If you ever tried to compile C++ code with different compilers you would know why it's a wise decision.
The set of warnings is vast and not standardized so you take C++ source from project. It compiles for them but doesn't compile for you because you use different compiler or enabled different set of warnings. At which point you either try to get the other project to "fix" something that isn't an issue for them or you do stupid, pointless, time consuming work adjusting your build system.
The same would happen in Go and it would be a reusability killer. You use some library in your program but it doesn't compile because you decided to use more strict set of flags.
Lack of warnings switches also simplifies the toolchain. In go it's just `go build` and it works.
In C++ you have to write some kind of makefile because everyone executes `cc` with different set of flags.
Re: Russ Cox is stepping down as the Go tech lead
#277Earlier quoted context omitted.
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-7dfda8a1...
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
Re: Russ Cox is stepping down as the Go tech lead
#278> 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.
Re: Russ Cox is stepping down as the Go tech lead
#279Earlier quoted context omitted.
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.
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.
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.
Re: Russ Cox is stepping down as the Go tech lead
#280IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.
I did mean to ask: who "owns" Go for all practical purposes? I suppose in theory it's some independent entity/commitee/whatever, but who pays the majority of the people working on it? Google?
Checking the 20 top contributors from https://github.com/golang/go/graphs/contributors
Google: 10
Unclear: 7
Tailscale: 1
Canopy Climate: 1
Isovalent: 1
Just checking the GitHub profile and not doing any deeper digging, so take it with a grain of salt.