I've said this before, but the rust community really seems to attract the most toxic and drama-thumping types as their icons. I'm not really sure why such types are drawn to it.
First of all because we're talking about the kernel community here, which was incredibly toxic and dramatic long before Rust even existed. Linus has chilled out in the past few years but that legacy isn't entirely gone.
C++ drama has nearly come to fistfights at conferences, and the only reason that doesn't get talked about more is that the toxicity stays mostly on private (not public) mailing lists as a result of the more insular nature of that ecosystem. Nowadays you have a lot of people just quitting over things like the fact that a member of the standard committee was convicted on CSAM charges.
There are plenty of "C supremacists" in the tech influencer community and the maintainer mailing list of every distribution.
And streamers like PrimeTime that eagerly jump on every opportunity to shit on Rust and actively dump gasoline on every flareup of drama for ad revenue.
In general, programmers seem to love being elitist about languages and tools. Remember how everyone used to dump on PHP constantly?
Discussions on the internet often were dramatic. There are certainly also many "C supremacists", but I don't generally see C people coming to C++ or Rust projects and insisting that it should be rewritten in C because "C is better". I believe C is a better language myself and definitely much better than how it is currently perceived, but I do not mind if other people have a different opinion and do projects using other languages. While the mindset of many C++ and Rust proponents seems to be that "C has to die", so is inherently much more hostile. This makes it then sometimes difficult to ignore this completely.
I'm a Rust coder who also occasionally watches Prime, and I've never seen Prime casually pour gasoline on fires. Yes his whole business model is reacting to whatever content is hot right now, but he always does so in a considerate and non inflammatory manner.
He's not a fan of Rust for totally legitimate reasons.
He is apparently mostly a Golang guy, and has stated he would play around/experiment with Zig. However, this was against the advice of Muratori (who does not like Zig), and suggested Jai (preferred choice) or Odin.
My experience with Rust and people who use Rust has actually been great.
There seems to be an entire second world of “Rust community” and Rust zealots online who are heavy on the drama, though. It really does feel like an alternate Rust universe.
Although when I think about it, several of my other interests and hobbies are exactly like this. Great in the real world, but as soon as you step into certain online spaces it’s drama and toxicity.
In this specific case, I think this is more about kernel drama than Rust drama.
I don't think that's true. I think the C guys told themselves that writing safe C code is just a matter of skill, but data shows that the amount of skill necessary to avoid writing unsafe C just isn't there. The average C developer isn't as competent as they claim.
You can lie to yourself and say that the same security problems exist in other languages, but that isn't true.
When I check the vulnerabilities marked as HIGH on a JVM based project, it's often banal stuff like a denial of service in Spring. The consequences of an attack are a few days of downtime until we patch the library, but the truth is that while downtime on our application might be profitable for a competitor, it's not profitable for a black hat hacker working alone. They can't blackmail us, because we can update the library without paying them to stop.
Meanwhile the average C vulnerability is usually some form of RCE that would let the hacker install ransomware.
Rust is sadly more about marketing than actually being popular or safe.
That stackoverflow survey rust folks so proudly crow about shows it’s the #1 ‘admired’ language, well #2 was closure and Zig over the years which clearly shows the value of the survey. Just marketing slop.
The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
The rust community unearned arrogance is only surpassed by the Haskel folks. It’s breathtaking. Yes yes not all in the rust community are like this, but the social media amplified squeaky wheels one sure are loud.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
That was 2022. I am aware of at least one security bug in their Rust code, but it wasn't a memory safety issue. I'll be interested to see what they say when they post updated numbers.
> "The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions."
"it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks"[1]. Using the Rust keyword 'unsafe' doesn't make the code inside it the Wild West or automatically an exploit or a problem, it is a limited-scope relaxing of only some checks.
> The rust produces safe code claim is also marketing garbage. The rust standard library has over 7.5k (of 35k) unsafe functions in it. The core library has 7K (of 21k) unsafe functions. So any Rust program that claims not to have “unsafe” code is most likely not true since any program that doesn’t use the standard library is a toy.
Why does any of that imply that Rust doesn't produce safe code? There's no argument here - just some numbers and unjustified conclusions.
Java also had its share of remote code execution attacks. Security is quite complex ___domain and it is not just memory overwrites that can allow RCE attacks. Though I can agree that in average C/C++ is more vulnerable.
Most CVEs for Java are about untrusted code escaping the sandbox. No one is saying JavaScript is a bad language for server side development despite browser sandboxes constantly leaking.
Yes, there was a popular logger library that was written badly that tried to interpret log messages as potential source for fetching code dynamically from remote locations. Something that was thought to be the future 25 years ago, but had mostly been abandoned in all modern code.
I think already phrasing it like this "the C guys" is inflammatory and not helpful. The C community is huge and there is also a large part interested in more secure programming. Also the idea that tall C code is hopelessly unsafe while all Rust code is perfectly memory safe are both far from the truth. In reality, you can make C code quite good and you make Rust code very unsafe. While Rust certainly has some advantage, this is not as black-and-white as the Rust marketing wants you to believe. But this fuels the "C must die" and "we are on the right side of history and if you can not see this, you are an enemy" lines of thinking some people have.
It also doesn't help that the Rust comes with more than just the safty changes. The expectations for development models, distribution models, backwards compatibility guarantees not to mention the cultural aspects are very different which is the real reason it causes so many clashes.
It get pushed with the argument for better memory safety but then wants to change the entire world as well.
From shaming everything else as either slow or unsafe to rewrite the universe, the Rust community makes it hard for new comers to consider the language by its merit.
But the good thing is, the hype has settled down and Rust has found its niche. It’s not tackling Go or Python anytime soon and competes in a different plane.
Zig is another great alternative for someone like me who never found Rust a pleasant language to work with.
Any trending language will attract some not so great people who make their choice of a shiny language their whole personality. It's really a pity for rust to be in that position now, as those people are there for the feeling of superiority and will cause drama to get it
If rust ends up being mainstream successful, those people will move on to something else and start attacking rust for whatever they feel their new language is superior in
Someone should have hugged them when they were kids
I don't care as I don't use rust. I learned and played with it, it is just horrible. I use Python, Golang and C almost everyday for living and fun!
Just hate the fact that quite often people get judged or even treated differently just based on the languages they choose to use. It is just a tool, nothing different from a screwdriver.
This is unfortunately my take with almost every interaction I had with the Rust community. Expressing any diverging opinion is enough to get ostracized.
It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now.
If only just a kernel that can run server like application without a gui shell.
There are many Rust OS mentioned in this thread. (Eg Redox)
But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a ___location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
Do you mean ___location as in different subsystem than dma, which is required for all modern devices.
Or just ___location as in stash the files outside the dma directory?
> Or just ___location as in stash the files outside the dma directory?
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
