Rust Developers Move Ahead With Preparing To Upstream More Code Into The Linux Kernel

[cj.wijtmans]

There are a couple of them, but the issue is that C and C++ don't provide enough information for the compiler or static analyzer to know what the code is supposed to do. Most of them will have a set of macros, but they're not standardized, they're pretty ugly, and you need to make sure to use them.

Again not a c++ issue. A tooling issue. While debugging there is plenty of information, sometimes even the code itself is inside the debug information. The issue is that its third party and not by the toolchain itself. The information not being there in a release build is a good thing. Theres memory safety then theres other security issues with too much information in a binary.

[cj.wijtmans]

IMHO the "lack of standards" and "centralised tooling" criticisms miss the main point: standards matter when and only when the implementations are proprietary. Rust, including its compiler, library and all the tools are open source. They can't lead to a lock-in situation and they can't leave you stranded if the proprietary compiler suppliers disappears or decides to end support.

In fact, in a FOSS world a standards-driven programming language can be a hindrance, not a benefit. Take C++: virtually every compiler in existence implements standards incompletely, but at the same time adds its own extensions. In other instances, two compilers will behave differently even though both are technically compliant with the standard. The fact is that every nontrivial project needs to be developed with a specific compiler in mind. Case in point: Linux itself. It took clang a while before it was able to build the kernel (and it took considerable effort both on clang's part and on the kernel's part), and no compiler other than gcc and clang can reliably build it. It's much easier to develop software when you know that it will always use the One True Compiler rather than deal with the minefield of various partially compatible but subtly different implementations.

You can turn on strict c++ so no extensions are used. Compilers behaving differently is a good thing as long as they follow the c++ standards. What is the issue?

[cj.wijtmans]

Language needs to work together with tooling to make it efficient. You can make a lot of things into tooling for C++ but it won't be required in language itself. If it won't be required then a lot of projects simply won't use it. As you said "C++ CAN have memory safety" it's only "can". It's not and it will never be necessary due to backwards compatibility. In Rust it's not "can". It's simply a thing and you can't just not use it. It's core part of language and language doesn't exists without it, unlike C++. That's why despite C++ can have many things, it won't be better than language that is actually built around these things.

C++ is efficient so what are you talking about?

[dragon321]

No i stand by what i said. C++ standard is only syntax and STL and some minor things such as main(), RTTI, globals. All of the underlying work is up to the tooling. C++ CAN have memory safety its just never worked on by the tooling implementations. It even took google to make ASAN. C++ is also getting modules and its taking a long time to implement. I dont hold my breath for memory safety to be standardized though because its completely out of the scope of the C++ syntax. Unlike rust which has centralized tooling.

Language needs to work together with tooling to make it efficient. You can make a lot of things into tooling for C++ but it won't be required in language itself. If it won't be required then a lot of projects simply won't use it. As you said "C++ CAN have memory safety" it's only "can". It's not and it will never be necessary due to backwards compatibility. In Rust it's not "can". It's simply a thing and you can't just not use it. It's core part of language and language doesn't exists without it, unlike C++. That's why despite C++ can have many things, it won't be better than language that is actually built around these things.

[GrayShade]

Which architectures will be supported? If we see for example some PCIe device drivers or file systems in Rust in the future, I hope some niche architectures are not left without support. I know there is gcc rust compiler in pretty good shape and will be part of GCC 13 officially (so probably May 2023), which does support quite a lot of platforms, but not sure what Kernel will use by default. I had various issues with standard rustc compiler, not playing nicely with some tools.

That Rust GCC front-end is completely irrelevant here, and only exists to appease people who insist on having multiple implementation of a language, with the results described in the post above mine.

The project you want to follow is rustc_codegen_gcc. It uses the rustc front-end (and standard library, of course), with GCC as a backend, for code generation. This means that rustc can emit code for almost any target supported by GCC, without forking the language.

[jacob]

Modern C++ compilers has ASAN. I dont know if that would make it "memory safe" but its pretty much similar to rust that it can be turned off and on. Again the issue is not with c++ its with the implementations and tooling. Rust syntax cringes me out but also its centralized tooling and lack of standards are scary as well. You can see why big corp are pushing out.

IMHO the "lack of standards" and "centralised tooling" criticisms miss the main point: standards matter when and only when the implementations are proprietary. Rust, including its compiler, library and all the tools are open source. They can't lead to a lock-in situation and they can't leave you stranded if the proprietary compiler suppliers disappears or decides to end support.

In fact, in a FOSS world a standards-driven programming language can be a hindrance, not a benefit. Take C++: virtually every compiler in existence implements standards incompletely, but at the same time adds its own extensions. In other instances, two compilers will behave differently even though both are technically compliant with the standard. The fact is that every nontrivial project needs to be developed with a specific compiler in mind. Case in point: Linux itself. It took clang a while before it was able to build the kernel (and it took considerable effort both on clang's part and on the kernel's part), and no compiler other than gcc and clang can reliably build it. It's much easier to develop software when you know that it will always use the One True Compiler rather than deal with the minefield of various partially compatible but subtly different implementations.

[GrayShade]

You would need a static analyzer that can catch all runtime errors (and then manually fix all of them) before execution to get similar memory safety. This one claims to be able to do that:

https://www.absint.com/astree/index.htm

The pricing is not public, so it is likely exhorbitantly expensive, which is why most C++ developers have likely never heard of it.

There are a couple of them, but the issue is that C and C++ don't provide enough information for the compiler or static analyzer to know what the code is supposed to do. Most of them will have a set of macros, but they're not standardized, they're pretty ugly, and you need to make sure to use them.

[darkonix]

No i stand by what i said. C++ standard is only syntax and STL and some minor things such as main(), RTTI, globals. All of the underlying work is up to the tooling. C++ CAN have memory safety its just never worked on by the tooling implementations. It even took google to make ASAN. C++ is also getting modules and its taking a long time to implement. I dont hold my breath for memory safety to be standardized though because its completely out of the scope of the C++ syntax. Unlike rust which has centralized tooling.

Don't hold your breath. C & C++ just can't be "fixed" for memory safety. Modern C++ and tooling advances are really nice but many companies including Google say Rust is the way to go for writing future code that is safer.

[cj.wijtmans]

So...the issue is with C++?

No i stand by what i said. C++ standard is only syntax and STL and some minor things such as main(), RTTI, globals. All of the underlying work is up to the tooling. C++ CAN have memory safety its just never worked on by the tooling implementations. It even took google to make ASAN. C++ is also getting modules and its taking a long time to implement. I dont hold my breath for memory safety to be standardized though because its completely out of the scope of the C++ syntax. Unlike rust which has centralized tooling.

[bachchain]

I do not like the ideology of accepting something that enjoys deprecating technology in secret or in a subdued manor.

Well, for a while we tried doing it loud and obnoxiously, but people seemed to hate that even more, so I'm not exactly sure what you want from us.