Rust For The Linux Kernel Sent Out For Review A Fourth Time

[Volta]

Actually if you get serious enough they don't depend on C.

Maybe not in everything, but they actually do. In many cases there's no kernel, but plain C on micro-controller.

[Volta]

Actually, the most successful OSs (and their predecessors) were written in System 360/370/ESA/Z assembly language and (in some cases) PL/X. z/OS, z/VM, z/TPF, z/VSE are the current variants. While you may never have heard of those OS's, they do run a significant part of the underlying infrastructure and would be considered advanced and successful.

They're hardly the most successful OS's. Not even close to Linux popularity and wide scope of usage. However, assembly language and C aren't exceptive.

[Volta]

Rust makes the same thing to the programming problem. The restrictions imposed by the ownership rules, make it possible for the compiler to track the lifecycle of a program object from the start to the end. This is why Rust's compiler can catch a lot of bugs at compile time.

To be honest I'm not against Rust. The only language I considered worth to learn was C (and assembler, but it was long ago), but Rust may be the next one. I need a programming language for micro-controllers and I hate C++. I even prefer to write my own functions in C instead of using scanf() or stupid fgets().

[jacob]

To be honest I'm not against Rust. The only language I considered worth to learn was C (and assembler, but it was long ago), but Rust may be the next one. I need a programming language for micro-controllers and I hate C++. I even prefer to write my own functions in C instead of using scanf() or stupid fgets().

Using gets() should be a criminal offense but other than that C is in many cases (unfortunately) still the go-to language for microcontrollers. The reason is binary size. In Rust virtually everything uses generic types (even in libcore) which need monomorphising. The resulting binary is often significantly larger than if it was written in C. For many applications it's the price worth paying for Rust's advantages (and honestly whether an executable is 20kb or 500kb absolutely doesn't matter on a PC), but with a 16-bit address space it's a problem.

[Volta]

Using gets() should be a criminal offense

Fortunately, I've never used it.

but other than that C is in many cases (unfortunately) still the go-to language for microcontrollers. The reason is binary size. In Rust virtually everything uses generic types (even in libcore) which need monomorphising. The resulting binary is often significantly larger than if it was written in C. For many applications it's the price worth paying for Rust's advantages (and honestly whether an executable is 20kb or 500kb absolutely doesn't matter on a PC), but with a 16-bit address space it's a problem.

Nevertheless, I'll probably start learning Rust. I'm going to develop on PCs as well.

[Alexmitter]

Rust support can be merged if it supports at least half of those architectures: Alpha, ARC, ARM, C6x, C-Sky, H8/300, Hexagon, IA-64, m68k, Microblaze, MIPS, NDS32, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, Unicore32, x86, Xtensa

And at least both GCC and LLVM.

To compile rust on anything then x86_64 and Aarch64 is pure pain, if that does not change, there is no future for that.

[pabloski]

Rust support can be merged if it supports at least half of those architectures: Alpha, ARC, ARM, C6x, C-Sky, H8/300, Hexagon, IA-64, m68k, Microblaze, MIPS, NDS32, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, Unicore32, x86, Xtensa

Rome wasn't built in one day. x86_64 and ARM are the most used ISAs today. This means that Rust is ready to replace C for a lot of drivers.

And at least both GCC and LLVM.

Why GCC? The kernel can be compiled with Clang too. And Clang today is on par with GCC. There are very few corner cases where Clang produces binary code that is incompatible with GCC. So you can even compile Rust parts with Clang and the rest with GCC.

[AmericanLocomotive]

I'm not a fan of rust, whether iron oxide based or language.

Look at rust's history of support.

Litterly took a crap on older CPU's lacking SSE2 CPU optimization while supporters kept the bugs or lack of support extremely quiet, all awhile furthering it's own agenda in-filtering top coding projects in order to enrich it's own fame. Reminds me of Ubuntu and SystemF.

On the flip, rust will likely have a very successful time of further deleting all of the older (and slower) CPU code from the kernel, making the kernel smaller and faster!

The last x86 CPU that didn't support SSE2 came out in ~2002. So you won't be able to run the latest software on 20 year old x86 CPUs. I think we'll survive.

[billyswong]

The last x86 CPU that didn't support SSE2 came out in ~2002. So you won't be able to run the latest software on 20 year old x86 CPUs. I think we'll survive.

Well, there are always some strange products like this https://www.phoronix.com/scan.php?pa...inux-Detection
From that presentation slide, they are still introducing new x86 CPU in 2018. However, according to the news writing their whole series aren't even fully i686 ready.

[qm3ster]

In Rust virtually everything uses generic types (even in libcore) which need monomorphising.

I wonder if explicitly typing some generic functions you actually do use with many types (and not something that compacts greatly from monomorphization, like iterator chains) to take `&mut dyn Trait` would produce code sizes closer to C. A common example could be when you pass many structs implementing `Serialize` to the same data format.