News for hackers. Stuff that matters.
[dead]
Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @10:15AM (#32925454)
I think this is basically nonsense. Some of most toxic comments I have ever encountered on HN are people whining about Rust. I've said it before and I'll say it again -- some Rust users need to be confident enough in Rust to allow others to disagree, but, mios dio, it's not as if their interlocutors have found some sweet spot of high minded debate.

Moreover, "toxic", to me, is not well-meaning, generally positive people excited about something legitimately technically interesting and new. "Toxic" is repeated flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..." and "Rust doesn't fix ALL BUGS so why even bother?"), mole hill matters of taste ("Egads! The syntax!"), and drive by hype hate (I'm glad the hype has died down enough for Forth to be usable).

I gag on this "toxic" line every time I read it, because it usually also includes a boring, retrogressive, small beer, almost American politics-style argument. The joke that comes to mind is we are about 15 minutes from someone claiming "The coastal elites want to force you to use Rust." Yesterday, I saw two comments, one of which claimed Rust was a conspiracy against C++ programmers, another that admitted anti-Rust fervor was about resentment. The energy is they don't want you to win. They are keeping you down. Just yuck.

Re:Next steps for Rust in the kernel by jamincan on Wednesday September 21, 2022 @11:48AM (#32926846)
I used to wonder who these people are too, but I think they mostly aren't that visible or at least prominent in actual rust threads. But you do occasionally see drive-by posts in places like /r/cpp along the lines of "should I learn C++ and Rust?" along with a long list of why Rust is so much better than C++. I'd sour to Rust too, if that was my primary interaction with the "community".
Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @12:43PM (#32927760)
> I'd sour to Rust too, if that was my primary interaction with the "community".

Yeah, understood. I think we both know Rust people face a lot of the same level of criticism. And I get it. It's no fun. However, I don't think the way forward is to present the worst possible form of the argument (a strawman, "Rust people think Rust solves all problems", or, a vibe level: us vs them, "Rust people are toxic").

If I wanted, I could rake some C++ people over the coals for being toxic right now, and not just re: Rust, because C++ has more than a few hard core jerks. But whataboutism is just not helpful. I'm more interested in something more substantive/constructive.

Re:Next steps for Rust in the kernel by sidlls on Wednesday September 21, 2022 @12:55PM (#32927935)
That’s fair. I’d be interested in that, too. I just don’t see it as something a certain group is interested in.
Re:Next steps for Rust in the kernel by manfre on Wednesday September 21, 2022 @10:46AM (#32925934)
> "toxic", to me, is not well-meaning, generally positive people...

The self proclaimed intentions or excitement of people has no bearing on whether or not the environment they create is toxic.

Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @10:57AM (#32926086)
I don't necessarily disagree. There can be a "toxic positivity". So, partially agree, but I think this side of the argument needs to be more fully fleshed out, and, if this is to be a serious criticism, I think the anti-Rust folks need to, for lack of a better word, lead, and be examples non-toxic behavior. Posting unserious vibe level HN comments is not leadership.
Re:Next steps for Rust in the kernel by manfre on Wednesday September 21, 2022 @12:36PM (#32927647)
If group A creates a toxic environment and group B reacts (and potentially contributes to) the toxic environment, why would it fall upon group B to lead fixing the situation? Your disagreement aligns with victim blaming.
Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @12:51PM (#32927865)
> If group A creates a toxic environment and group B reacts (and potentially contributes to) the toxic environment, why would it fall upon group B to lead fixing the situation? Your disagreement aligns with victim blaming.

I strongly disagree with this sentiment for lots of reasons. Most significantly, because who is to say who created the environment? This is a lesser form of debate sometimes used in American politics, and I'd prefer not to engage in it -- "Rs did Y first, so we Ds are completely justified in doing X."

Moreover, your characterization of anti-Rust folks as somehow "victims" is fundamentally ridiculous. Get a grip.

This isn't leadership. This is nursing resentment.

Re:Next steps for Rust in the kernel by allisdust on Wednesday September 21, 2022 @10:34AM (#32925742)
I have a theory that all new rust programmers either become evangelists or haters based on whether they are able to cross the borrow checker barrier or not.
Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @10:51AM (#32926005)
I mean that isn't a terrible theory. Love and hate is often forged in an initial "I hate this." TBC I hated the borrow checker once too! My fear are the people who make these love/hate decisions based on vibes instead of experience. I'm perfectly okay with someone who tries Rust/Java/OCaml and says "Never for me. Not again." I'm less okay with these technical disagreements becoming more tribal. I think C vs. C++ is often tribal. Because I like Rust, I really hate the idea Rust opinions might be tribal too.
Re:Next steps for Rust in the kernel by throwaway17_17 on Wednesday September 21, 2022 @11:05AM (#32926194)
I agree with the sibling comment that your theory probably has some merit. However, it does leave out a class of individuals like me. I tried Rust, had no issue with the borrow checker. But I think that is because, IMO, using Rust is predicated on programming, and designing programs and algorithms, in the way Rust wants them designed. So, when using Rust I just accepted that my code needed to fit what Rust thinks is proper and will accept. There are plenty of other reasons not want to use Rust and to not want to see the language become the front runner in some sort of ‘race to replace’ other systems level languages. But I’m sure there are more knee-jerk reactions that become entrenched opinions than those opinions formed like mine.
Re:Next steps for Rust in the kernel by pohl on Wednesday September 21, 2022 @11:02AM (#32926152)
There might be some merit to that, although it could just be the case that they just don't like the idea of a compiler telling them what they can and cannot do.
Re:Next steps for Rust in the kernel by mustache_kimono on Wednesday September 21, 2022 @01:42PM (#32928571)
"Hey man, don't harsh my buzz. I want give out two mutable aliases to this underlying value. I know what I'm doing."

Narrator: He didn't know what he was doing.

Re:Next steps for Rust in the kernel by nyanpasu64 on Wednesday September 21, 2022 @02:12PM (#32928962)
Giving out two mutable aliases to an integer or struct holding integers is perfectly safe in C and C++ and JS and Java and Python... and perfectly safe in Rust if you hand out multiple &struct and mark each field as Cell<T> (just with painful syntax compared to any other imperative language in existence).
Re:Next steps for Rust in the kernel by mort96 on Wednesday September 21, 2022 @11:21AM (#32926405)
Rust has attracted a large share of evangelist, because the problem it solves is one which other languages don't; guaranteed safety without being a managed language. And that is genuinely something to be excited about, and if more of the code that's currently C or C++ was Rust, we would probably have fewer security issues.

My guess is that you're lumping all Rust evangelists together in one bucket and thinking of them all as "toxic evangelists", when a lot of them are just people who want the computing world to be better.

Re:Next steps for Rust in the kernel by sidlls on Wednesday September 21, 2022 @12:53PM (#32927895)
Rust has some safety guarantees and it is strictly better in that regard than C++. But it’s not a panacea, and the footprint of `unsafe` buried in so many crates is worrisome, especially when novice systems programmers see “guaranteed safety” and make assumptions that aren’t necessarily valid.

Aside from that I very carefully and clearly did not lump all Rust evangelists in a single bucket.

Re:Next steps for Rust in the kernel by mort96 on Friday September 23, 2022 @04:04AM (#32949203)
You know that your points aren't very interesting. We value languages like C# and Python for their safety, even though we know that libraries sometimes contain C code which may have bugs and that the implementation is in C or C++ and might have bugs and it runs on an operating system which contains C and assembly code and might have bugs. There's a huge value in knowing that the code you write won't have memory problems, and you recognize that with all other languages. Your vendetta against Rust prevents you from recognizing the exact same thing when applied to a language you don't like.
Re:Next steps for Rust in the kernel by rvz on Wednesday September 21, 2022 @09:31PM (#32933850)
> But it’s not a panacea, and the footprint of `unsafe` buried in so many crates is worrisome, especially when novice systems programmers see “guaranteed safety” and make assumptions that aren’t necessarily valid.

On top of the tens of thousands of crates that (ab)use unsafe everywhere and programmers importing lots of packages and installing hundreds of transitive unsafe packages, using an NPM-style package manager and marketing this as "guaranteed safety" does sounds very much like the Rust hype-squad are over hyping their snake oil to push the cargo cult.