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

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

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

[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]

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

[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]

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.

[shmerl]

Yeah, zero cost is a bit of a misnomer, but what they mean is trying to minimize that cost as much as they can. And in most cases it is indeed equal to not using an abstract data structure and such.

[STiAT]

Type safety probably is the biggest one. But lack of more powerful abstractions is also a major pain point. Rust at least attempts to provide what they call "zero cost" abstractions. Which in theory should be better than both C (not enough abstractions) and C++ (not zero cost abstractions).

The main premise of Rust is to allow producing both performant and memory safe code, which neither C nor C++ can do both at the same time.

While I am not so sure about the "zero-cost" abstraction; I see we're on the same page there. But since no language (I know) could deliver zero cost abstraction yet, there is not much to loose. While not "zero-cost" probably a "less-cost". But I agree, we're pretty much on the same page here. Thank you for your opinion, very welcome.

[shmerl]

I think the main reason Rust uses macros for vec initialisers is that because unlike C(++) its syntax doesn't allow variadic functions.

I think I've seen an explanation that they could implement something like {a, b, c} syntax for initializers, but decided not to becasue that implies non trivial cost and they didn't want that to look easy in order not to be misleading. C++ adds a lot of code around that for example. But it is a much nicer syntax than what Rust is proposing to use.

[jacob]

Yeah, the terminology is a bit mixed up, but I mean it in Rust's way. C++ doesn't attempt doing that.

Rust also tries to avoid hidden performance overhead caused by syntax, which results in more verbose than C++ expressions sometimes (that's why there are no neat array / vector initializers in Rust for example and they prefer to use macros for that). That is also in line with their zero cost abstraction approach.

I think the main reason Rust uses macros for vec initialisers is that because unlike C(++) its syntax doesn't allow variadic functions. That's the same reason why println is a macro and not a function. There is of course hidden cost in Rust and it doesn't always do zero-cost in the C++ sense. For example even if you don't have any "dyn trait" variables in your code, I'm not sure that it doesn't still generate vtables. It also uses fat pointers in a way that's totally transparent to the source code and that can bite you when using FFI.