I don't see how a different programming language would help improve the ratio of maintainers vs developers.
Source? AFAIK the kernel is probably one of the most, if not the most, well-funded and maintained open source projects.
Such a functions are exported to a public kernel API sometimes. So any kernel developer could call them. It make unavoidable a mistake of a programmer, when some of those functions was called with an unknown at compile time integer value. It is not a bug as it is, code would compile and work nevertheless, code would be bigger that it could be, maybe slower, that's all. But reviewer should be finding such a misuse of API.
It is just one example, linux kernel uses a lot of tricks and exposes it via APIs, reviewer must be aware of all of them and to check everything by itself.
Compare it with Rust. In rust one can encode a lot more limits on the right use of an API than in C. Encode and enforce. Even when rust sometimes cannot do it, rust have nice macros, instead of C's macro-horror. So a lot of mistakes that could be made with C, could be avoided with Rust. So it would be easy to review code, it would take less time from a reviewer to review code.
Reading other people's code is boring. Linus stated once that he got around that by retyping the code while reviewing, which is a good technique.
One danger is of course the change in culture and politics should Rust actually become prevalent. But there is still BSD.
"We do not have enough maintainers. We do have a lot of people who write code, we have a fair number of maintainers, but... it's hard to find people who really look at other people's code and funnel that code upstream all the way, eventually, to my tree... It is one of the main issues we have."
The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference counters, or dynamic behaviour, which is very easy to search for.
Vec + generational indices might be the other way, is that preferred over Rc?
Most of the times it isn't. Just as an example here's a random part of serde, the high quality serialization library in Rust:
https://github.com/serde-rs/serde/blob/master/serde/src/priv...
The amount of extra automatic memory management is often a good indicator of not well thought out data structures (although of course they are not always needed).
But I suspect there are probably more people who are experts in device driver code and know kernel internals than all people who know rust.
Why not Ada/SPARK though? Was it ever considered, even?
Despite its ubiquity, the Linux kernel is not actually the golden standard for safety or performance. Not even for code quality. Ada remains the language of choice in areas where safety is actually crucial. Rust isn't going to take it's spot either.
If any of you reading this comment is interested, you may want to check out my previous comments regarding Ada.[2]
By the way, just to be on topic: I found Linus' opinion on Ada vs Rust here: https://news.ycombinator.com/item?id=20838125. He said "We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters.". That is all though, he does not get into explaining why he believes Ada to be a disaster. Again, "I do not see any reasons given for why he considers Ada a disaster. Cannot really do much with this opinion as it is."
[1] Some people claimed that it is a legacy language which is just simply not true. I would suggest that they give https://blog.adacore.com/ and https://blog.adacore.com/gnat-community-2020-is-here a read.
[2]
https://news.ycombinator.com/item?id=19122884 (!)
https://news.ycombinator.com/item?id=19245898 (!!)
https://news.ycombinator.com/item?id=19274244 (!!)
https://news.ycombinator.com/item?id=19274412
https://news.ycombinator.com/item?id=19770405
https://news.ycombinator.com/item?id=20776296
https://news.ycombinator.com/item?id=20934511 (!!) [3]
https://news.ycombinator.com/item?id=20939336 (!!)
https://news.ycombinator.com/item?id=21286061
https://news.ycombinator.com/item?id=21286292
https://news.ycombinator.com/item?id=21435869 (!)
https://news.ycombinator.com/item?id=23609499 (!!)
[3] The last link in that comment returns 404, here is a working one: https://www.ei.tum.de/fileadmin/tueifei/rcs/becker/spark2014...
If there are any other broken links, please, do let me know!
> Standard Ada supports safe use of pointers (“access types” in Ada) via strongtype checking, but safety is guaranteed only for programs where there is no explicit deallocation of pointed-to objects
This validates "With Ada you can't use dynamic memory allocation and pointers safely, unless you buy into SPARK". (GC not relevant in this context.)
> In this work, we propose a restricted form of pointers for Ada that is safe enough to be included in the SPARK subset. As our main contribution, we show how to adapt the ideas underlying the safe pointers from permission-based languages like Rust [3] or ParaSail [13]
This validates that the pointer support in SPARK "post-dates Rust".
"heavier-weight" is arguable. I'll withdraw that assertion. SPARK is definitely less expressive than Rust though; it doesn't have lifetime variables, and it doesn't allow borrows of stack values:
https://blog.adacore.com/using-pointers-in-spark
> The most notable one is that SPARK does not allow general access types. The reason is that we did not want to deal with accesses to variables defined on the stack and accessibility levels.
- do I really need threads when I can share non-mutable messages or copies of same? Maybe (speed, throughput). Maybe not. Depends. What's clear is I need choice.
- how do I get correctness? Rust maybe checks for index bounds. But in C++ I just relegate that to a library and voila std::string/vector.
I am concerned for Rust: placing too much emphasis on correctness through language alone seems to be a weak point. Correctness through libraries and augmenting with formal tools seems like a much stronger solution.
That being said, apart from a good stdlib, I found Rust much easier than C due to a consistent type syntax, sum types, generics, traits, and the compiler hitting me on the head with lifetime errors.
Having the compiler enforce some of these invariants for you might well end up making writing the code easier, not harder. Rust has a steep learning curve, that's absolutely true, but in my experience I feel a lot more at ease writing complicated parallel code with complicated ownership models in Rust than in C.
C is a trickster: in practice if you want to write correct C code you have to use a memory model very similar to that of Rust, the main difference being that Rust forces you to do it (mostly) right whereas C will gladly let you write completely broken code.
https://doc.rust-lang.org/std/sync/atomic/fn.fence.html exists, but Rust can't force you to say, use the correct ordering.
The person who submits the code has to do more work up front to satisfy the Rust compiler that there are no ownership issues, data races, etc. Maintainers have less work to do because, assuming the code compiles and does not use unsafe blocks, they can be confident the invariants promised by Rust hold. You have moved work from maintainers to submitters. (But you have also given submitters a way to get quicker, automated feedback on their work.)