Hacker News Reader

Comment by daptaq | Hacker News Reader

I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical perspective. Has the Rust-portability situation been addressed? Or will this change restrict the number of platforms the Linux kernel will be usable on? Assuming that is the case (I remember reading that GCC will acquire Rust support), what will the advantages be? I would guess stability might improve due to more static analysis, but what about performance? Build-time? And will this have any effect on Rust?

View on HN

Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off.

The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc.

As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development.

The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.

The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.

> The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.

Do you have a link to some of the discussion around this? I'm curious to hear what kernel devs thought of the driver and how it was introduced to them. Is there a talk about it? Or mailing list archives? (Or both?)

From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)

I was very put off from Rust because of the people acting out those stereotypes that I've encountered whenever the topic comes up. But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I don't think we should be rewriting a ton of software just because there's better compiler-level safeguards, but it does make it much harder to shoot yourself in the foot without realizing it. There's some issues, dynamic linking isn't really supported. I've had good luck with various embedded targets, having trialed STM32F4s, RP2040, ESP32-C3, and am waiting on getting an NRF52840. Surprisingly, the ESP32-C3 is the best out of the box experience I've had, but library support is just not there.

IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.

> But then I decided to just learn it (partially driven by work requirements), and it's honestly great.

I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use. It's not even close to mature enough to consider using except for test projects. It doesn't fix programmer errors despite every rust user trying to convince me otherwise that all imported crates are perfect.

I like the idea of the language somewhat but the entire ecosystem ruins it for me.

> I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use

I've encountered none of this. Of course Cargo is going to have broken libs, it's just a package repo like npm, pypi (+ pip), etc.. The differences between "editions" is pretty large, but I haven't seen much reason to not use the latest release in most cases. The tooling out there is very good at supporting multiple toolchains simultaneously (though, not in the same project, necessarily).

> It doesn't fix programmer errors despite every rust user trying to convince me otherwise

No engineer who knows what they're talking about will ever say this. You're either spewing lies or are believing the words of people who have no idea what they're talking about, neither of which are good. Rust helps prevent a specific class of memory errors that are very common in C (and to a lesser extent, C++). It still gives you the `unsafe` escape hatch that lets you do almost anything you can do in C.

> It's not even close to mature enough to consider using except for test projects.

Our production hard-realtime control system begs to differ.

> Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use.

Can you give a concrete example of this?

What language and ecosystem do you like using? I'm curious as to what ecosystem isn't terrible unless it's just C with vendored dependencies.

> dynamic linking isn't really supported

This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust code that isn't really supported. Dynamic linking with e.g. C libraries is a breeze.

You can of course link with Rust code that exports a pure C ABI. Such code works just like a shared library coded in C/C++.

I'm not sure how useful that would be since people pin specific version of libraries with Rust. They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken.

Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.

> They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken.

Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.

If there's an exploit/problem in, say, a crypto library, Rust's ecosystem seems less resilient. Instead of just updating the library system wide, you have to get everyone to rebuild their applications with a safe version of the library (if it's even possible).

This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.

On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once)

There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell

But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem

> On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once)

As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big.

I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491

I wholeheartedly agree. It's the one worry I have with a language that I otherwise love.

(Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)

> Has the Rust-portability situation been addressed?

The rust portability story is in the process of being addressed, by two different projects:

gcc-rs[0] adds a Rust frontend to GCC.

rustc-codegen-gcc[1] adds a GCC backend to rustc.

Both are progressing pretty well, but it will likely still take a while until they reach maturity.

> Or will this change restrict the number of platforms the Linux kernel will be usable on?

There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.

> what will the advantages be?

There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).

As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.

[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/

[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/

There are two in flight projects to bring GCC to Rust: gccrs and rustc_codegen_gcc. These both seem to be making good progress. Otherwise, right now Rust is only being included for drivers, so doesn't have as many portability concerns.

What are the negative stereotypes you associate with Rust and Rust programmers?

The belief that the problem of memory safety that Rust has some compile-time protections against is the only problem (or so much more important problem that the rest almost don’t matter) of programming, and that therefore Rust is the only sane choice to use for any project. There’s a reason that memes like “Rust Evangelism Strike Force” exist.

That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.

Uh, what? I’ve found Rust as a project and community to be a very self criticizing group - they know when they’ve got it wrong.

They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.

In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe and everyone should migrate to Rust. They might not represent everyone from Rust but that is the part of the Rust community that the C++ community sees the most.

Not sure what to do about that really, but I think it caused many C++ programmers to hate the language before they even tried it.

> In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe

Experience shows that memory safety issues are the most common cause of security issues.

Microsoft:

>As we’ve seen, roughly 70% of the security issues that the [Microsoft Security Response Center] assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated.

https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

Google:

>Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week.

https://www.zdnet.com/article/chrome-70-of-all-security-bugs...

You clipped that quote, the aggravating part is where they say that everyone who writes C++ needs to migrate to Rust. Even if it is/was true that will still anger a lot of people when it get posted in every thread about C++.

That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety.

Microsoft:

>we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.

First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead.

We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide.

When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible.

Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms.

https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

> That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety.

Sure thing but can Rust live up to its memory-safety promise? Or even data-race freedom promise?

I must say that, coming from systems programming background, I was always skeptical about those promises because IMO these problems fundamentally cannot be solved in bare-metal programming language. They're implied by the complexity of HW not loop-holes in programming languages.

That said I see nothing wrong with Rust but I think that people are vastly overselling its core features while at the same time a quick glance over https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust will give you exactly a list of bugs which Rust seems to promise not to run into.

Another very recent example, and a very good blog post about memory corruption taking place in Rust: https://www.graplsecurity.com/post/attacking-firecracker

That's not a good reason to hate Rust, in my opinion. The community around it, maybe (although "hate" is a strong word), but not the language.

From my experience, the stereotype is that they are very positive within their own community, very loud and negative towards anything not in the Church of Rust. Of course, this doesn’t fit most Rust programmers, most I’ve met are great people and developers, it’s just the loud people getting the attention.

I have a word in mind, but before that I would ask: what are some safety-critical systems written in Rust? If there are any, how big a role does Rust play in their safety properties? Is it much different from any other programming language?

I can already hear faint exclamations about the language's age, but are Rust programmers justified in putting forward claims about safety? Or do they shift to using the word in the sense of "fewer bugs in this particular class" (and nevermind any other effects the language may have on development).

Even if we take such a narrow and distorting view of "safety", we can look at, say, "The Power of Ten" and ask how does Rust use fare with each rule, and is it any more advantageous than other languages in use by safety-critical systems.

I'm curious what caused you to be so annoyed with the language that you had to create a user name out of it :)

I don't think anyone ever said it was completely safe. This is a pre-conception on the part of the critics. Every Rust resource I looked at stated that the toolset exists to support inherent safety, but there is still a contract with the programmer that requires them to know what they are doing.

Rust is "safe" and other languages are "unsafe". Haskell is "pure" while other language are "impure". Some macro systems are "hygienic" while others are "dirty". It is not an accident that the humpty dumpties (language designers) chose to use these particular terms for their semantic distinctions. It's useful for propaganda. The mind encounters a colloquial term and equivocates. This happens in both the critics and the evangelizers. Inferences drawn are then often unjustified.

Agreed, it does appear to be heavily sponsored and marketed. And you are correct that these pre-conceptions affect advocates as well! But I think the push for wide-scale acceptance is not unreasonable. If it is completely necessary I suppose only will be known sometime in the future.

The simple fact that they call themselves rustaceans and evangelize the language. It feels the language spread via a religious uprising rather than merit of making good programs easy to write.

Being put off by the evangelizing I can certainly understand – but surely the name "rustaceans" is just some innocent humor.

In order to be one of the cool kids you have to identify as one. From my point of view the self identifying and adopting a title is key to the indoctrination process.

> In order to be one of the cool kids you have to identify as one.

You really don't? Every time I read a comment like this, I think, "Who hurt you?"

I like Rust the language, and i have found most people in the community to be smart and reasonable. But i also find "Rustaceans" to be rather cringe. I don't think it's specific to Rust; i think this need to form a visible community identity, a brand really, is very common in Silicon Valley culture. Hence why most startups there have cutesy names for employees, people go round sticking logos of software they use on their laptops, etc.

The crab is cool though. As language mascots go, it's a lot more adorable than the Gopher or that LISP alien thing, and almost as adorable as Bjarne Stroustrup.

Ahh yes. Unlike the pythonistas, the gophers, the ziguanas, the lispers, the perl monks, ...

I love Rust, it's the most fun I've had programming since first discovering the concept as a kid, with the possible exception of the time I was enamored with Haskell. But one stereotype that I've faced a lot is in connection with the ecosystem. In particular, if you're not satisfied with "rustup everything, then let cargo pull all your deps from crates.io, it just works" as a way of work, you'll sadly face quite a bit of hostility from parts of the community. Seriously; a programming language or its community shouldn't dictate how I assemble and build code! Luckily there are exceptions, and more importantly, the toolchain and ecosystem seem to be getting better in these regards all the time.

Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).

Rust community is nice until you use unsafe.

More seriously, the number of peoples you can have a sane discussion about unsafe use is quiet low because when you need to use unsafe is because of a complicate/hard to explain/understand problem.

This combined with the (99% of the time valid) safety dogmas brings some to instantly tell you how to not use unsafe with blatantly bad workaround without considering why you _would_ use unsafe at the first place.

This safety/anti-unsafe dogma makes some peoples far too vocal.

I consider Rust community to be nicer with time, seriously, but I can't say this "I don't understand your problem, but I saw a unsafe, here is a code that doesn't use unsafe" is not a thing. Of course, it's changing, because Rust is more widely use, and "here is when you need unsafe" patterns are emerging. As a Rust user, I'm happy.

> the number of peoples you can have a sane discussion about unsafe use is quiet low

There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_o...

Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.

> the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue.

I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really.

Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens.

> Sometimes the unsafe patterns we bring with us just don't match the Rust model.

I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.

> now peoples try to understand why you need unsafe

I think that was always the case. actix is a singularly unique example, and I had never seen anything like it before or since. Not even close. There just hasn't been any Rust project with that kind of popularity that also contained egregiously unsound code. So we're not just talking about unnecessary use of unsafe here, but egregiously unsound usage of unsafe.

The attitude toward 'unsafe' has pretty much always been the same. Use it. It exists for a reason. But make sure it's justified and strive for soundness.

i might be wrong but currently rustc is based on llvm so any platform llvm cant target, rust can target. For the linux kernel it seems like they want to use a gcc frontend for rust (gccrs) that is currently under development. So with gccrs rust should be able to work on any platform gcc supports thus giving it the same portability of the current c code in the kernel.

Reply on news.ycombinator.com