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.
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.