Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

271–280 of 396 posts

Re: Russ Cox is stepping down as the Go tech lead

#271

> 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.

As long as they aren't so disinterested that they become absentee leaders. It's rare for huge successful projects you've heard of, but I think the typical project is more likely to have this problem, although maybe it's just incompetence too.

Re: Russ Cox is stepping down as the Go tech lead

#272
post #90

Earlier 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…

> You may be surprised to learn that the rest of us don't talk to anyone like this.

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

#273
post #216
post #122

Earlier 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…

> It's impossible to write complex and performant programs without pointers.

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

#274

Earlier 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

I do agree with his point that the implicit mutation of the loop body for an iterative will be difficult to debug.

Re: Russ Cox is stepping down as the Go tech lead

#275
post #19

Earlier 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…

"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.

Re: Russ Cox is stepping down as the Go tech lead

#276
post #238
post #231

Earlier 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.

Why is it a problem?

`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

#277

Earlier 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

Not obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.

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.

Remember when they tried to king George Washington?

Re: Russ Cox is stepping down as the Go tech lead

#279
post #144
post #142

Earlier 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.

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.

Re: Russ Cox is stepping down as the Go tech lead

#280
post #5

IMHO 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?

> 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.
Post reply on HN