GCC Rust Approved By Steering Committee, Likely To Land For GCC 13

[Alexmitter]

Or you could port LLVM to these architectures, which might turn out to me be less effort and have more benefit in the end.

why would you port new platforms to a bad compiler if there already is full support in a truly great compiler.

[Alexmitter]

I thought the borrow checker is an integral part of rust, how can it even work without that?

They do not want to implement the borrow checker themself, they want to leverage a existing compatible implementation.

[Sin2x]

Holy moly, the linked post is so full of things I'd like to counter but that would take too much time.

What really struck me was this:


This is plain stupidity and/or stubborness and/or denial.

Being proud to use a language that makes it easy to segfault or buffer overflow is... I lack words.



Tell that to decades old buffer overflow bugs in critical software.. kernel, ssl, core utils, su, ...
Because that's sooo good to have than just to replace programs from decades ago, with a programming mindset and tooling from decades ago, in a language that prevents you from doing errors or even stupidity (I'm more clever than the compiler, let me use this ubercool trick because I'm a laet programmer).

Gosh, people need to realize programs are not about them or their ego, it's about the users and assets those programs get in contact with - which are to protect at all costs, with the most effort on preventing damage; neglecting this because of ego is... I lack words again.

Your goshes and holi-molies will not hide the fact that you have missed the point of the article: Rust is a badly designed jack-of-all trades language that has only one thing going for it -- and this thing, safety, is irrelevant to kernel programming. If you want to replace your application's C++ code with Rust, I will not say a word, by all means, go for it. But for system kernel Rust is iniquity.

[archkde]

I thought the borrow checker is an integral part of rust, how can it even work without that?

The borrow checker is just that, a checker. It is an extremely useful part of the development experience, but correct code can be compiled without consulting the borrow checker (as well as some incorrect code that rightfully doesn't pass the borrow checker).

[Alexmitter]

Everything you need to know about Drew DeVault's Rust analysis :
> Safety. Yes, Rust is more safe. I don’t really care.

And his points on that are completely correct.

[debrouxl]

Drew DeVault - a.k.a SirCmpwn in another community which he attended earlier/younger and wasn't quite entirely appreciated because of some of his posts and actions - has produced a significant number of posts and code bases in the recent years. Many of those are thought-provoking and at least interesting; some of them are even useful / very useful.
"Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows." is one of the things he's wrong about, indeed. It's a clear fact that Rust isn't a silver bullet for everything, but making brand-new unsafe languages in reaction to safer languages such as Rust is a step in the wrong direction, for users' sake.

[archkde]

The funniest thing is that the context of this post is specifically kernel programming -- where writing non-unsafe code is impossible by definition.

I don't see why this post should have a kernel programming context. Anyway, writing non-unsafe code in a kernel is not only possible, but in fact a very good idea. Sure, you need to implement some things using unsafe, but then you build safe abstractions over it. No more forgetting about "this function needs interrupts disabled and the RCU lock on xyz held", the compiler will complain to you. I can imagine this to be particularly useful with regards to resource management (maybe even userspace vs kernel resources), as well as concurrency (think interrupts, preemption, SMP and a userspace constantly waiting to exploit your bugs).

[archkde]

why would you port new platforms to a bad compiler if there already is full support in a truly great compiler.

Why would you want to create a bad frontend for a new language when there is already a fully supported, truly great compiler.

[Sin2x]

I don't see why this post should have a kernel programming context. Anyway, writing non-unsafe code in a kernel is not only possible, but in fact a very good idea. Sure, you need to implement some things using unsafe, but then you build safe abstractions over it. No more forgetting about "this function needs interrupts disabled and the RCU lock on xyz held", the compiler will complain to you. I can imagine this to be particularly useful with regards to resource management (maybe even userspace vs kernel resources), as well as concurrency (think interrupts, preemption, SMP and a userspace constantly waiting to exploit your bugs).

This post has a kernel programming context because inclusion of Rust into GCC is motivated politically -- as a requirement to allow Rust in Linux kernel. There is no other reason.

As for safe/unsafe code in kernels -- your point has architectural sense only if the whole of the kernel is written in Rust. Linux kernel is not and thinking that it is going to be fully rewritten in Rust is delusional.

[Quackdoc]

Should have been Zig (or nothing, nothing works for me too). Rust is an overhyped buzzword pushed by the corporations and their zombified zealots.

Translation: "easy safe code is overhyped"