Live data from Hacker News

Russ Cox is stepping down as the Go tech lead

groups.google.com

311–320 of 396 posts

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

#311

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

The whole idea is a joke, it's right there in the name. It was a recognition of the "facts on the ground" of GvR's role as the creator of Python, it was never seriously meant as a principle of project management. It's descriptive not prescriptive, eh? The idea got reified all out of hand.

The wording may be a joke but the concept is real and widely used.

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

#313

Earlier quoted context omitted.

To be fair, with Go it's still painful to work with private repositories. And I'm invoking Cunningham's Law here when I say there's no convenient way to do so. If you want to use a private repository (let's say it's a private GitHub repository), then you either have to do it the bad way (setting up your own GOPROXY and setting it up securely, which implies also ensuring it's not leaking your source code elsewhere for…

1) git config --global url.ssh://git@github.com/.insteadOf https://github.com/ 2) export GOPRIVATE='github.com/_company/*'

>> or the worse way (doing brittle text replacement using weird git config stuff).

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

#315
post #235

Please make more Ivy videos

I think you might be thinking of Rob Pike's project, unless Russ has been involved? https://github.com/robpike/ivy

https://www.youtube.com/watch?v=ek1yjc9sSag&list=PLrwpzH1_9u...

I don't intend to make more of those, but that was a lot of fun.

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

#316

Boy, this makes me sad. He’s really changed my life, I’ve learned so much about software and programming from his writing and thinking. I wish it didn’t have to happen, but I guess it’s only ever a matter of time.

Happy to hear that. Still going to write and think. :-)

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

#317

Earlier quoted context omitted.

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…

Here are some other projects that benefited from BDFLs in my opinion: * 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.

A perhaps important clarification:

Many of those, including Linux as far as I know, simply started as projects that were driven by single authors with a strong vision and remarkable diligence.

Then people flocked to those projects, but with the understanding and appreciation of that vision.

I don’t think any of them wanted to be BDFLs for the sake of power. They were the original authors and _made_ something useful. I don’t think any of them took over an existing project and declared themselves dictators. Ironically they all would be way too opinionated to do so.

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

#318
post #286
post #130

Is the new tech lead more likely to get rid of the glibc-isms that Golang won't let go of, like crashing if non-ELF standard parameters like env aren't passed in ELF library initialization, or maybe supporting global-dynamic thread local storage so we can dlopen() shared objects made in Go on platforms that don't hack like glibc? Go's obsession with glibc-isms is really unfortunate, and it's been many years. If you'r…

Here are some citations since people seem to be just downvoting because they don't like the message: Go requiring non-ELF standard parameters for initialization of supposedly "C ABI" libraries, open since 2015. https://github.com/golang/go/issues/13492 The Go project specifically acknowledging the glibc-isms here: "All Linux first class ports are for systems using glibc only. Linux systems using other C libraries are…

If you just want to run Go programs on Alpine, it works fine. (I put some effort in back in Go 1.21 to make sure that the downloaded binary toolchains for Linux even work fine on Alpine.)

If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.

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

#319
post #130

Is the new tech lead more likely to get rid of the glibc-isms that Golang won't let go of, like crashing if non-ELF standard parameters like env aren't passed in ELF library initialization, or maybe supporting global-dynamic thread local storage so we can dlopen() shared objects made in Go on platforms that don't hack like glibc? Go's obsession with glibc-isms is really unfortunate, and it's been many years. If you'r…

golang's priority is "works inside of google" and everything else tends to be a bit of a fight

This is definitely not true. "Inside of Google" would have been just linux/amd64 for a very long time. Now it includes linux/arm64 too, but that port happened before Google needed it. And all the other ports are not used inside of Google, except maybe the Mac port if you count developers laptops.

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

#320
post #132
post #5

IMHO Go has been one of the best-managed open source projects ever. Hats off to Google for supporting it.

Yeah, only supporting glibc behaviors and ignoring the ELF standard at will really qualifies as best managed. /s

I replied to the other copy of this comment: https://news.ycombinator.com/item?id=41136122.
Post reply on HN