Rust Null Block Driver Published To Begin Experimenting With Rust For Linux Storage

[mdedetrich]

You absolutely can write perfect code in C. You really believe you can't write a single function perfectly? And if you can write one perfectly, you can write two perfectly. And so on. Yes, it takes more time and attention to detail to not write bugs in the first place. More than most managers want to allow time for. That largely is not a FOSS issue though unless you're being paid to write FOSS for a company.

Thats not how software programming works, the complexity of the program scales exponentially with the amount of combinations in your code which is exactly how even the best C programmers in the world create bugs. The exception to this is if you can prove that specific parts of your programs and hence combinations of those specific which is exactly what Rust's borrow checker does for memory access.

The irony when you tell someone they are unqualified and then goes on proving you don't know anything about Rust. 10/10 had a good laugh.

It's interesting that those who dislike the language the most is those who haven't used it.

There is an extremely large correlation between those that dump on Rust and those who have no idea what they are talking about.

[TheCycoONE]

Using a slower, fatter language for convenience in instances where speed and memory usage matter greatly is not the answer or the Linux kernel would be written in Java. The answer to bad coders is not putting training wheels on bits of the kernel where they're a big detriment, it's not allowing bad coders to contribute code to those areas in the first place.

Not sure if you read the fine article but the Rust implementation is faster.

C has a weird mythical status but it does not model real hardware anymore and it should be possible to write languages that produce faster binaries with idiomatic code. Rust isn't that language but it does have one advantage over C - noalias by default.

[piotrj3]

You absolutely can write perfect code in C. You really believe you can't write a single function perfectly? And if you can write one perfectly, you can write two perfectly. And so on. Yes, it takes more time and attention to detail to not write bugs in the first place. More than most managers want to allow time for. That largely is not a FOSS issue though unless you're being paid to write FOSS for a company.

So, yes, in numerous real world situations you have the perfectly viable option to trade development time for code tightness.



You missed that every last bit of data that is not of a known size at compile time requires a slight overhead that it would not in C. It's not a huge overhead, in fact it could be summarily dismissed entirely on something not taking much in the way of external data or not needing to be as efficient as possible. Over something the size of a kernel it adds up though.

I do code in Rust. This is not just some hater casting stones. But neither am I an unthinking fanboi who denies its shortcomings. Rust is quite good at doing what it does. It's even amazingly efficient at it, given the guarantees it offers. But it's not now and can never be as tightly coded as well written C, it can only beat bad or average C. Sometimes this doesn't matter. But sometimes it does.

Problem is complexity raises the moment you write 2nd function. and after even more when 3rd function. And it keeps raising to a point perfect isn't possible or crafting one would require heat death of universe time. Most FOSS code in stuff like Linux kernel is outcome of some company.

Check for size is actually even weaker in Rust. For example if you create vector with unknown size at compile time, but use iterator loop over it - you wont' have out-of-bounds check. If you make for loop that goes up to arrray.len() slice.len() or something... no bounds check..

Also Rust compiler is clever enough that if you make a single check before loop to ensure that stuff is in-bounds, no checks will be done later on. Eg:

    assert!(input.len() >= 3);
    // no bounds checks here
    let a = input[0];
    let b = input[1];
    let c = input[2];​

Will result in one of bounds check, not 3. But even if you had full out-of-bounds checking, typical performance loss for that reason is 1-3%, and at absolutly worst handcrafted scenario 15%.

[rclark]

Problem is complexity raises the moment you write 2nd function. and after even more when 3rd function. And it keeps raising to a point perfect isn't possible or crafting one would require heat death of universe time. Most FOSS code in stuff like Linux kernel is outcome of some company.

Makes me wonder.... All that complexity now put into the Rust compiler to supposedly help the so called programmers write memory safe code, layer upon layer of it... All in the compiler.... Even go as far to try to force a weird 'style' of writing as well (more code complexity). Not just checking language for syntax.... Hmmm.... A big turn off.

[lowflyer]

I'm kinda late to the party... some popcorn left?

The rust fans never fail to amuse me. All these fancy new concepts they vehemently refused with C++ they're embracing them now with rust.

[Siuoq]

Rust safely is enforced by the compiler, not during runtime so there is no performance penalty. This is funny: blaming me as 'unqualified' and immediately writing some factually incorrect stuff.
P.S. I've been programming in Rust since 2016.

This is total false.
I believe that you wanted to say that the rust compiler does type checking compile time. Which is true, but totally irrelevant. For example c compilers do the same.

What is relevant e.g. the fact that safe rust does runtime range check when accessing elements of an array, while in c you can omit that if not needed.

[dremon_nl]

This is total false.
I believe that you wanted to say that the rust compiler does type checking compile time. Which is true, but totally irrelevant. For example c compilers do the same.

What is relevant e.g. the fact that safe rust does runtime range check when accessing elements of an array, while in c you can omit that if not needed.

I would recommend you to read some basic books or articles about Rust memory safely, thread safety and how is it enforced by the compiler before writing something bold like "total false".
Runtime range check is optional (as already mentioned many times in the other comments) so if you need to squeeze picoseconds in some benchmark you can do it.

[chocolate]

The answer to bad coders is not putting training wheels on bits of the kernel where they're a big detriment, it's not allowing bad coders to contribute code to those areas in the first place.

Yeah, because "good coders" that are already there are in infinite supply, and we don't need to educate more. And we don't want to democratize programming in sensitive scenarios through better programming languages, either. I hope you do realize, now, that implicitly stating all that is... less than stellar?
At work, I once had to explain threading in C to a person with no software background whatsoever. As you might imagine, it's quite hard to be introduced to the C language through an embedded, threaded project, especially if you are a physicist hired by HR to fill an embedded programming role, because that's the state of things everywhere in defense, avionics, and space across Europe. Doesn't matter though, I sat down as patiently and as serenely as ever and tried my best to explain everything. That person went on to code a correct multi-threaded video algorithm the next day and completed all of it in record time. Like, hours. And I checked it, and the code was spotless. She's still there, putting other software engineers to shame every now and then.
Elitism does not belong anywhere, but especially not in software. Good thinkers and prolific people are out there. They might not always come to good terms with C, but they won't necessarily be at fault. They deserve better tools, be it Rust or something akin to Rust that may or may not come out in the future.

Also, you know what? I've met some self-proclaimed "good" C coders. My forum pal, the horror stories, you won't believe. I've actually grown more fatigued from battling with "good" C dwellers who haven't begun to understand the first thing about portable, not-too-horribly-ISO-deviating, industry-standard code, than from writing in C myself; and believe me, forum pal, believe me, I'm this close to leaving everything behind to become a farmer.

[marios]

Runtime range check is optional (as already mentioned many times in the other comments)

If it is optional, what is the compiler flag that disables it?

[soulsource]

[...]
You missed that every last bit of data that is not of a known size at compile time requires a slight overhead that it would not in C. It's not a huge overhead, in fact it could be summarily dismissed entirely on something not taking much in the way of external data or not needing to be as efficient as possible. Over something the size of a kernel it adds up though.
[...]

Could you please elaborate, in which situation you need a dynamic allocation in Rust, that you would not need in C? All cases I can think of (dynamic arrays, virtual function tables,...) have the same overhead in both languages.