Unsafe usage is quite small, at 10%, which seems good for a hardware device driver.
Unsafe usage is quite small, at 10%, which seems good for a hardware device driver.
Rust can go low-level, but its succintness (compared to C) is when dealing with high-level structures. Things like vectors, hashmaps, or even strings. Those rarely are use on a driver.
In addition to that: in C you can share a pointer in many places and write memory wherever you want. Since rust has ownership system things get a little more complicated. Sometimes you have to write extra code to appease the borrow checker.
Consider that you will never get the situations you get in C, where forgetting to check for NULL in one place can result in privilege escalations (example: https://www.exploit-db.com/exploits/33322/). I think it's worth it.
C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use, you couldn’t hand code any better. – Stroustrup
It's close to insignificant to comparing two languages. Especially when they boil down to things like:
let ptr = unsafe {
libc::mmap(
ptr::null_mut(),
len,
libc::PROT_READ | libc::PROT_WRITE,
libc::MAP_SHARED,
file.as_raw_fd(),
0,
) as *mut u8
};
vs calling something like this in one line in C, etc.The C version also crams every line together, the Rust version couples related statements but leave newlines between others (not sure if loc counts those too).
Of course, correctness trumps almost everything in programming. Rust seems like a really nicely balanced programming language that can replace C++ and C and provide additional protection against some kinds of common errors made by programmers. So it’s definitely on my list of languages to try next for a project.
Even so, 1300 vs 1000, or 1.3x is not really in the "so much more as to be more difficult to read" category.
In fact it can be in the "better worded and easier to read category" (e.g. a monolithic stream of code without functions and comments vs one with).
Rust might end up being just right, not too concise, like Haskell or APL, and not too verbose, like Java or Ada; it could be a Goldilocks language.
That doesn't apply to driver development, but it might be surprising to someone only moderately familiar with the language.