zlacker

[return to "“Rust is safe” is not some kind of absolute guarantee of code safety"]
1. kweing+O7[view] [source] 2022-10-02 15:10:51
>>rvz+(OP)
Classic Linus.

From the closing paragraph, I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.

◧◩
2. sidlls+2a[view] [source] 2022-10-02 15:24:45
>>kweing+O7
They probably are, in many cases. Rust’s community, in aggregate, have developed a reputation (earned, in my opinion). It’s too bad that the community don’t follow the leaders’ example in this regard. There are some quality, level-headed Rust advocates. They appear to be the minority.
◧◩◪
3. mustac+1e[view] [source] 2022-10-02 15:46:54
>>sidlls+2a
At least they don't go around slandering programming language communities.

If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling.

What some people don't understand is that the Linux kernel isn't 'led' in any meaningful sense. But I suppose some projects don't need actual leadership? I once was recommended a Metallica documentary, because "It's amusing to see what emotionally stunted 40-50 year olds who have never had anyone tell them 'No' since 18 will do." That's the Linus vibe -- somehow we've limped along to here. Seriously, read the rust/rust-lang issues/RFCs. Those people sound like grownups contrasted to this.

◧◩◪◨
4. turtle+sk[view] [source] 2022-10-02 16:22:54
>>mustac+1e
It might be difficult to back out kernel changes versus userspace changes. App-level concerns with leaky abstractions could follow functional programming, immutable state, fail-fast, and all sorts of gospel--but there's still a kernel doing stuff behind the scenes.

If the kernel acquiesces to certain philosophies that are opposite to its intent as-a-kernel for many other environments and contexts it must support, a cascade of later patches could derail things completely. It may become too much effort to undo, and the project must limp along--until that mountain of tech debt costs too much to fix.

Maybe the kernel cannot fail fast for good reasons. And the Linux project cannot fail fast for equally good reasons.

And possibly, if a technically compelling reason presents itself, Linus may fully back it--even contributing to that work himself.

[go to top]