> 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.
Russ Cox is stepping down as the Go tech lead
311–320 of 396 posts
Re: Russ Cox is stepping down as the Go tech lead
#312Re: Russ Cox is stepping down as the Go tech lead
#313Earlier 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/*'
Re: Russ Cox is stepping down as the Go tech lead
#314Re: Russ Cox is stepping down as the Go tech lead
#315Please 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
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
#316Boy, 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.
Re: Russ Cox is stepping down as the Go tech lead
#317Earlier 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.
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
#318Is 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 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
#319Is 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
Re: Russ Cox is stepping down as the Go tech lead
#320IMHO 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