Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity.
For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.
That's... an interesting point of view.
I personally find functional programming languages, including Rust, much clearer than C or Go, in particular because you can offload much information onto the compiler. The example of Serde feels a bit weird, because I don't think I've ever encountered issues with Serde code, while almost 100% of the times I've used Go in production, I've needed to debug through Go's Unmarshal and its... interesting implementation.
Also, last time I checked, the kernel didn't reject Rust. There was a conflict between two specific developers on the best place to store some headers, which is slightly different.
C is simple. Good, fast, secure C is complex.
Rust has a higher initial learning curve than C. But the gap between bare-minimum Rust and fast and secure Rust is much smaller than with C.
> The high complexity is intended to push more runtime errors back to compile time
I would almost say that the ergonomics of allowing this is almost as important as the borrow checker!
Yes, but :) Rust isn't complex because it has functional traits, but rather because of its other design choices. Complex, nonetheless, but, I'd also say, looks "scarier" from the outside. I recently gave in and learned it, and it's much easier to handle than I thought before.
I actually think Rust is pretty easy to pick up for anyone that’s written Typescript and can use their linter to understand references and unwrapping a Result and catching an error.
Beyond that, Rust has pretty forgiving syntax.
No Linux did not reject Rust from the kernel.
> Rust is a tire fire of complexity.
And C isn't?
It really isn't. C is very simple.
Yep, love the simplicity of the strict aliasing rule.
We are talking about two axis here:
- Complex by design
- Complex to use
C is complex to use because it is simple by design.
Though I would argue the absurd amount of undefined behavior makes it not even simple by design.
> Though I would argue the absurd amount of undefined behavior makes it not even simple by design.
What? UB is the simplest thing you can do when you just don't want to specify behavior. Any specified behavior can't be simpler that unspecified because it's just comparing nothing with something
Every part of rust is undefined because there is no spec. It’s whatever their compiler does.
Ferrocene has donated their specification to the project, so there absolutely is a specification now. What you can argue is that the memory model isn‘t fully defined, but it‘s almost certainly going to land somewhere around stacked borrows or tree borrows. Arguably C doesn‘t fare much better in that regard though as it doesn‘t even properly define its pointer provenance model either and Rust is much closer to defining its.
Oh something has changed in the last 6 months? glad they are making progress on the spec.
Note that, in compiler lingo, unspecified and undefined are two different things. C++ is specified to death, but full of undefined behavior (and also some unspecified behavior).
Rust is largely not specified, but aims to have no undefined behavior (outside of unsafe blocks).
I am aware but without a spec we don’t know which is which. You can’t say it has no undefined behavior because what happens is you try to specify it and find gaps or challenges.
In C undefined is used primarily when there is not a reliable and efficient mechanism for detecting a problem is happening. For example a C implementation may check every single invalid pointer deref, but more realistically it only detects only extreme out of range. So it’s undefined what happens.
> I am aware but without a spec we don’t know which is which.
I don't think I fully agree with this. A more accurate statement might be that "without a spec we don't always know which is which". You obviously don't need a spec to pin down at least some of a language's behavior, and even then the presence of a spec doesn't necessarily mean that you can answer arbitrary questions about what behavior is intended (c.f., various defect reports in the C/C++ spec asking clarifying questions, pointing out holes/deficiencies, or even admitting that certain behavior is not intended but being unsure about how to forbid it)
Good point.
That being said, at least in C++, undefined has been used largely as a joker for compiler optimizations. In Rust, if my memory serves, having the same code produce different results depending on the optimization level would be considered a pretty serious bug. In C++, it's par for the course.
I was going to roll my eyes at "Rust is a tire fire of complexity". Because it's not. Especially compared to C++. But then you just go on to outright lie in your second paragraph.
Dear Rust haters, lying about Rust in the Linux kernel is not effective for your cause, and in fact just makes it further look like you're throwing a tantrum. Downvoting me doesn't change the fact that more and more Rust is merged into the kernel, new, serious drivers are being written in Rust. It also doesn't change Firefox, Chrome, Microsoft, the US Government and others are recommending and writing new code in Rust. It's over, qq. It's absurd.
I really wish I could find the Lobsters comment the other day from someone that broke down the incredible list of nuanced, spec-level detail you needed to know about C++ to actually use it at scale in large projects. It's laughably, absurdly complex compared to Rust in huge code bases.