Comments by "" (@pierreollivier1) on "what is wrong with rust and linux????" video.
-
10
-
7
-
4
-
@MrZnarffy Agree by no means, was I trying to imply that C++ is good, hell no. For Rust I'm on the same fence as you. On one hand from my limited experience with rust (probably 20/30k loc). I think it's a great language to rewrite stuff, because when the problem space is solved you can really encode the correctness in Rust, and the compiler will protect you from making a lot of wrong assumptions in the future when working with the code. But despite all of it's features and facilities, I think that the kernel layer isn't well suited for Rust, it's not even about the extensive use of "unsafe" because even in "unsafe" block the compiler still offers better safety features than a C compiler. No the real problem with languages like Rust or C++, is that those language are harder to write kernel code, because the truth is that in a Kernel you need to squeeze every bit of memory, every cache line matter, every cache-miss is a loss. Unfortunately I find it extremely difficult in both Rust and C++ to manage the memory layout to fit the performance requirements of what's possible, grant it I wouldn't call myself a Rust expert, and obviously it's feasible, but the cost/benefit is IMO way to high right now. In languages like C/Zig/ASM, it's really really easy to actually "manage memory" you can exactly layout your memory for it to fit in cache, to be as tight as possible, and not waste ton of space, the current problem is that to achieve that result in C you have to walk on a very fine line were you can easily invoke UB by managing your memory with such precision. This is why I think a language like Zig (or any other language that has a modernized C semantic) is a better fit. Because the real problem with C is that the wobbly semantic and the poor ecosystem makes testing/debugging way harder than it should be. In Zig you have a lot of facilities in the STD and in the semantic that help you catch those bugs early. I think if C devs were given a language that has a very similar semantic but with better tooling, better defaults, better debugging/testing utilities they would easily write safer code, which again makes me really doubt that we will ever see a broader adoption of Rust in the lower layer of the Linux kernel.
3
-
Agree, In my opinion a piece of code can be qualified as "readable" if someone with any programming background can read it and understand it intuitively. This is why I love programming languages like C or Zig. They are both very easy to read and harder to write. This is also the reason I dislike C++ and complex Rust (because simple Rust reads really well). Both languages offer very complex syntax and encode way more information into the semantic, and while it might benefit the "experts" the truth is that it cannot be qualified as "readable" in the broader definition. If you look at the same code in the 4 languages mentionnned.
Zig code :
pub fn foo(allocator : std.mem.Allocator, n : usize) AllocatorError![]u8 {
const mystring : []u8 = try allocator.alloc(u8, n);
return (mystring);
}
C code :
char *foo(size_t n) {
char *mystring = (char*) malloc(sizeof(char) * n);
return (mystring);
}
C++ code :
std::string* foo(size_t n) {
std::string* mystring = new std::string(n, '\0');
return mystring;
}
Rust code :
fn foo(n: usize) -> String {
let mystring = String::with_capacity(n);
mystring
}
You can clearly see that the C and the Zig code are more explicit, in the eyes of everyone, the Rust example is really nice when you already know rust, but if I were to come from basically any other languages the lack of a return is very frustrating, also if I'm not familiar with String than I can't say if this code returns a dangling stack pointer ? in C++ if you don't know how the std::string works or what std:: is than it's quite confusing and again from just reading the code it's hard to know where the memory is coming from, The C code is a bit better, because the there is an alloc which takes the size of a char and mutiply it by N returning a char something, but still hard to know where the memory is coming from unless you know malloc, the Zig code on the other hand is IMO really explicit, because you can answer all the questions that you might have. Where is the memory coming from ? the Allocator. What is the function returning ? it returns an AllocatorError something something or an Array of u8. the allocator try to alloc n elements of the type u8 and returns it. Yes there is some subjectivity in readability but I think some objectivity can be found when you try to define "readability" as the proportion of code that one can clearly understand without being familiar with the language semantic.
1