Controversial opinion: There are only 2 kinds of people that think Rust will not become a widely used language:
- Those who don’t bother to learn it, and only argue about it without any hands-on experience, and
- those who don’t understand which niche Rust tries to fill.
For me it was funny, btw. I started out as basically a Rust fanboy, back when the “First Edition of The Rust Book” was still just called “The Book”…
Then I learned a bit of Haskell, and was immediately disappointed that Rust doesn’t offer the same convenience when it comes to working with Traits (cough Higher Kinded Types cough). So, while I never considered myself part of the first group, I definitely was part of the second for some time.
However, the more I’ve been trying to abuse Rust for stuff that would be better done in a higher level language (like Haskell), the better I understood why Rust doesn’t offer those abstractions: They often can’t be zero-cost, and using them in a language that tries to be very explicit about performance costs becomes very verbose… In other words, I learned the hard way what “systems programming” means in the case of Rust, and which languages it competes with, and which it doesn’t.
Yeah, I largely agree here. My coworkers are hesitant to try it because “it’s hard,” but honestly, it’s only hard for the first couple weeks until you really grasp borrowing and traits. It does nudge you into a different design, but that doesn’t make it bad, it just makes it a learning opportunity since the solution it nudges you toward is often better. That’s the first group, and probably the vast majority.
That said, I doubt it’ll ever become the #1 language, there’s just too many domains that don’t need what Rust provides. For example, we evaluated Rust at our org, and I ended up voting against it because we’d have to retrain everyone and we didn’t particularly need the performance and other benefits it provides. Maybe that’ll change if we get more people to join who are interested in Rust, but I’m not going to push for it unless we have issues that Rust would resolve efficiently. However, I’m using it for all of my personal projects, so I obviously see a lot of value there, just not enough to rewrite hundreds of thousands of lines of code.
The “it’s hard” claim is also a bit of a misconception imho. Rust for sure has a high entry barrier, but it isn’t particularly difficult, at least in comparison with C++, which I’d consider its biggest competitor. While it’s easy to start working with C++, it’s a horribly complex language with hard to use features, lots of weird edge cases, and tons of missing pieces, that one has little chance of ever learning properly, because it’s just so much to keep in mind at all times… Oh, and don’t get me started on how error prone memory management is without a Borrow Checker…
Sorry for the rant, back on topic: I agree that it’s not the right tool for many domains. That’s what I was thinking about when I wrote that people might misunderstand what niche it tries to fill. If one needs a low level language that is very explicit about performance costs, and offers memory safety and (some) abstraction at zero runtime cost, then Rust is definitely worth a look. If performance is not a key concern, then higher level languages might be a better choice, because one can build things faster, and focus more on the problem at hand instead of low-level details.
We are at work in a similar situation, as we would like to add another programming language besides C++ to our projects, and Rust is currently the top candidate. However, one of our goals is to use abstractions that are common in functional programming, and that’s where I think Rust is a suboptimal choice. I’ve been playing around with such abstractions in Rust recently (I’ve written blog posts about Free Monads and Reader/State Monads in Rust), and my conclusion is that Rust isn’t the right tool if one wants to use those. (Or, rather, those abstractions are not suited for the domain of systems programming.)
We are using Unreal Engine, so C++ is the obvious choice for performance critical code. Rust would then fill the same niche, and while it obviously would be much more convenient to use than C++, we would still need to train people, and set up FFI bindings. If we, however, are already willing to do that, we could also go all the way and introduce a higher level pure functional language. That way we would actually get a tool that covers a different domain and is suitable for abstractions coming from functional programming. We could then choose, based on a system’s requirements, if we need to focus on performance (-> C++), or if we can trade a bit of performance for much easier to write/maintain code (-> whatever high level functional language we pick).
That’s why, as it stands now, I also won’t push towards the adoption of Rust at work.
