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.
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?)
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.
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.
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.
Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
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.
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
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
(Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)
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'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.
Can you give a concrete example of this?
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/
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.
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.
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.
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...
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...
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
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.
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.
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.
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.
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.
You really don't? Every time I read a comment like this, I think, "Who hurt you?"
Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).
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.
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.
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.
The self proclaimed intentions or excitement of people has no bearing on whether or not the environment they create is toxic.
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.
Narrator: He didn't know what he was doing.
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.
Aside from that I very carefully and clearly did not lump all Rust evangelists in a single bucket.
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.