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

[RedEyed]

And his points on that are completely correct.

May I ask you then, what criterias are you referenced to to define the correctness of that statement?

Thanks.

[conner]

I find it incredible how easy it is to trigger Rust fans. I've never seen a language be held on an immaculate pedestal that to the extent that Rust is.

[Anux]

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).

Yeah makes sense that way, its essentialy an "unsafe" rust compiler but if you put in good/save code it will be ok.

https://drewdevault.com/2019/03/25/R...placement.html

Those points in his "critic" don't sound like he even considered rust and just tried to find points to reinforce his bias. Rust can be completly equivalent to C if you don't use all those features and slap a big "unsave" around your code. Then you can do everything with more rust code, not shure what one would gain from that because we allready have the C language for that.
And calling it a copy of C++ is also nonsense because C++ doesn't have an automatic memory management with zero runtime cost or even something compareable to save rust.
And why wouldn't one be able to use save rust in kernel developement? Just use unsave only on small sections that are not doable with save rust and everything should work just fine.

[archkde]

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.

Complete nonsense, the post was neither motivated by the creation of a Rust compiler for GCC, nor was the latter effort driven by the desire to include Rust in the Linux kernel (in fact the plan was, and still is, to use rustc for compiling any Rust code Linux).

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.

Of course I don't expect all of Linux to be rewritten any time soon (because a rewrite would be a lot of effort, LLVM doesn't support all relevant targets, and Rust doesn't support the Alpha memory model). Of course adding new Rust code does not magically make the parts written in C any safer than they currently are. But the architecture I mentioned also makes sense in driver code (the safe abstractions can even be shared between drivers), and in fact some of the worst Linux security holes were resource management and concurrency errors in undermaintained driver code. Rust can help a lot here.

[archkde]

Yeah makes sense that way, its essentialy an "unsafe" rust compiler but if you put in good/save code it will be ok.

Actually now that I thought of this a bit more, I think my statement was incorrect. I don't see how to properly compile (correct) code relying on non-lexical lifetimes without at least a partial borrow checker.

[Anux]

Actually now that I thought of this a bit more, I think my statement was incorrect. I don't see how to properly compile (correct) code relying on non-lexical lifetimes without at least a partial borrow checker.

That was my idea too, how can it manage the memory without knowing about lifetimes? Possibly they mean, you won't be warned about errors on compile time but it still does a basic lifetime analysis. But at that point one would have all the necessary info to warn the user.

[mmstick]

People are forgetting that Rust exists precisely to write unsafe code, and to make it easier to maintain and verify it. It has a lot of tooling for doing precisely that. There's much that you can do to codify unsafe logic to make it safe to interact with on a higher level. Even within the context of a kernel. The whole point of using Rust is to have access to all these language concepts and tools.

[piotrj3]

If you wanted to be enlightened, you would already be -- but you don't -- because you a blind zealot which I have already pointed out.

There has been a plethora of analyses of why Rust is a poor imitation of C++, my favourite one is from Drew DeVault who got so fed up with Rust fanatics preaching on every corner, he created his own systems language:

https://drewdevault.com/2019/03/25/R...placement.html

https://harelang.org/

This is probably the most useless article I have ever seen.

Not only half of claims are false, but since 1.00 forward Rust has to be backwards compatible. This implies that Cargo isn't mandatory for stuff he claimed. Also most issues pointed out that "C has a spec" doesn't happen because of forced backwards compability. Behaviours do not change.

C doesn't compile well on diffrent compilers. MSVC C, GCC C, Clang C, are essentially to a lot of important projects entirly diffrent languages. Kernel doesn't like Clang much, a ton of programs written in MSVC C doesn't like Clang or GCC, also GCC rust is comming which also gives competing implementation.

Concurency is not "bad thing" it is necessity because we keep growing in more cores/threads, but performance in single threaded scenario isn't improving that much. So going into future we have to employ some level of concurency. Fact Rust exactly adresses that problem is probably THE MOST important issue it adresses. For some things you need both better concurency tools, and you cannot have garbage collector. And so far only Rust gives answear.

Safety is directly tied to program stability. And in the end I would be happier to run program in Ada Spark Rust then C because if programmer for both has the same idea about logical/business errors, there will be way less errors unrelated to business. In fact Ada/Spark/Rust also has some tools to decrease some logical errors (technicly in some structures like Rust match statement you need to predict every possible outcome).

The thing is Rust actually does have (or by time of writing article had) few legitimate issues many of the were outlined by Linus Torvalds before letting it into kernel (like for example that kernel cannot panic!)

[archkde]

That was my idea too, how can it manage the memory without knowing about lifetimes? Possibly they mean, you won't be warned about errors on compile time but it still does a basic lifetime analysis. But at that point one would have all the necessary info to warn the user.

… and the answer is that non-lexical lifetimes only affect the borrow checker, and not memory management. Drop::drop still runs at the end of the lexical scope (and the borrow checker does take this into account).

[ssokolow]

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

The borrow checker just checks that your code is valid. It's not involved in translating it to machine code once the checks pass.