I know Rust bills itself as a replacement for C++, but the people I personally know who are actually interested in Rust are largely coming from higher level languages, not C++. The C++ devs I know generally say, “I know how to use C++ safely, why do I need Rust?”, whereas the higher level language devs are finding value in typing (optional typing in Python, Typescript, etc) and figure they might as well go all the way and get even stronger guarantees and better performance from Rust.
As an anecdote, I worked on a game project with a hardcore C++ dev, and they expressed interest in Rust so I offered to build the server in Rust. I used Actix and the server worked pretty well, but the C++ dev ended up rewriting it in C++ after I bailed on the project (time constraints). To be fair, this was early days for async Rust (before async/await), and my fist major project using async in Rust, but despite expressing interest, they just fell back to what they knew.
C++ programmers seem to be pretty stubborn about their tools, probably because it’s so complex and there’s a certain “right of passage” to learning to use it safely. I’ve seen a lot more willingness to relearn and retool from higher level language programmers.
or we can trade a bit of performance for much easier to write/maintain code
That’s our exact situation as well.
In our case, we have an R&D team that works in Fortran to generate our simulations, and my job is to put that into production. They’re concerned with getting the simulation running correctly, not performance. The code is structured poorly, so it would need to be refractored to take advantage of threading.
Our app is in Python, so our choices are:
refactor in Fortran to use multiple cores - the R&D team isn’t familiar with threading, and dev team isn’t familiar with Fortran
rewrite in Python
rewrite in a systems language (Rust was #1 candidate)
So I (relatively senior) built a POC in Rust, and my coworker (relatively junior) wrote it in Python. The naive Rust code was faster, though I was able to help get the naive Python code to be faster with a little fiddling (used numba for easy parallelism and performance boost). I didn’t bother cleaning up the Rust code (could’ve used Rayon or something to beat Python+numba) because we found we could use naive Python and get most of the performance without having to retrain anyone.
I still really want to use Rust and think it would be a fantastic addition to our stack, but I look back at that C++ dev experience and really don’t want to push for retraining stubborn people unless I absolutely have to (we have ~40 devs total, only me with Rust experience). That said, 2-3 of my coworkers seem seriously interested in learning Rust, so maybe that’ll change in the near future (we have other large projects coming soon that could benefit from Rust, like big fluid simulations).
I think Rust is good, and the main limitation I’ve had with it is a lack of other Rust devs. That seems to be changing, so I think we’ll see more projects like mine choose Rust instead (I would’ve pushed for it if we had just 2 other devs who know Rust decently well).
We are in a better situation regarding the addition of new languages. Most of our devs (don’t know the exact count, 40-50 I guess) are dissatisfied with C++ in one way or another. Our company started out with Unity (which uses .Net), so most of our senior devs have experience with other languages too, and those who don’t are generally young people who haven’t had time to get stubborn yet 😜.
Our technical director pushes towards functional programming pretty strongly, and he gave most of us the opportunity to participate in a course by FP Complete, which was a bit about Haskell, but mostly about Rust. So, most of our coders have at least seen Rust. Some liked it enough to do spare time projects in it, and as far as I can tell there is no strong dislike towards the language from anyone in our team.
However, there is no consensus yet amongst seniors which language besides C++ we should introduce. Our tech director leans towards Rust for business reasons (-> the argument is that many devs like Rust, so finding Rust devs should be easy). Some, though they dislike C++, would rather keep it exclusively, as they doubt the benefits of other languages would outweigh the overhead (training, writing FFI bindings). Then there are those (including me) who would go directly for a pure functional language…
And last, but not least, there is the biggest reason why we haven’t introduced any languages besides C++ yet: Time. We would need time to experiment with integrating languages into our tooling, and we simply are too busy at the moment to do that…
Our org pushes OO quite a bit, so I’d need to push for a change in development methodology. However, in practice we do something in the middle between OO and functional, and I’ve been pushing to go a bit more functional.
We have leeway here since we use microservices, so using Rust in just one part of the app wouldn’t be too disruptive. However, our teams haven’t specialized, so we’d need at least one person per team that’s comfortable with Rust.
I know Rust bills itself as a replacement for C++, but the people I personally know who are actually interested in Rust are largely coming from higher level languages, not C++. The C++ devs I know generally say, “I know how to use C++ safely, why do I need Rust?”, whereas the higher level language devs are finding value in typing (optional typing in Python, Typescript, etc) and figure they might as well go all the way and get even stronger guarantees and better performance from Rust.
As an anecdote, I worked on a game project with a hardcore C++ dev, and they expressed interest in Rust so I offered to build the server in Rust. I used Actix and the server worked pretty well, but the C++ dev ended up rewriting it in C++ after I bailed on the project (time constraints). To be fair, this was early days for async Rust (before async/await), and my fist major project using async in Rust, but despite expressing interest, they just fell back to what they knew.
C++ programmers seem to be pretty stubborn about their tools, probably because it’s so complex and there’s a certain “right of passage” to learning to use it safely. I’ve seen a lot more willingness to relearn and retool from higher level language programmers.
That’s our exact situation as well.
In our case, we have an R&D team that works in Fortran to generate our simulations, and my job is to put that into production. They’re concerned with getting the simulation running correctly, not performance. The code is structured poorly, so it would need to be refractored to take advantage of threading.
Our app is in Python, so our choices are:
So I (relatively senior) built a POC in Rust, and my coworker (relatively junior) wrote it in Python. The naive Rust code was faster, though I was able to help get the naive Python code to be faster with a little fiddling (used numba for easy parallelism and performance boost). I didn’t bother cleaning up the Rust code (could’ve used Rayon or something to beat Python+numba) because we found we could use naive Python and get most of the performance without having to retrain anyone.
I still really want to use Rust and think it would be a fantastic addition to our stack, but I look back at that C++ dev experience and really don’t want to push for retraining stubborn people unless I absolutely have to (we have ~40 devs total, only me with Rust experience). That said, 2-3 of my coworkers seem seriously interested in learning Rust, so maybe that’ll change in the near future (we have other large projects coming soon that could benefit from Rust, like big fluid simulations).
I think Rust is good, and the main limitation I’ve had with it is a lack of other Rust devs. That seems to be changing, so I think we’ll see more projects like mine choose Rust instead (I would’ve pushed for it if we had just 2 other devs who know Rust decently well).
We are in a better situation regarding the addition of new languages. Most of our devs (don’t know the exact count, 40-50 I guess) are dissatisfied with C++ in one way or another. Our company started out with Unity (which uses .Net), so most of our senior devs have experience with other languages too, and those who don’t are generally young people who haven’t had time to get stubborn yet 😜.
Our technical director pushes towards functional programming pretty strongly, and he gave most of us the opportunity to participate in a course by FP Complete, which was a bit about Haskell, but mostly about Rust. So, most of our coders have at least seen Rust. Some liked it enough to do spare time projects in it, and as far as I can tell there is no strong dislike towards the language from anyone in our team.
However, there is no consensus yet amongst seniors which language besides C++ we should introduce. Our tech director leans towards Rust for business reasons (-> the argument is that many devs like Rust, so finding Rust devs should be easy). Some, though they dislike C++, would rather keep it exclusively, as they doubt the benefits of other languages would outweigh the overhead (training, writing FFI bindings). Then there are those (including me) who would go directly for a pure functional language…
And last, but not least, there is the biggest reason why we haven’t introduced any languages besides C++ yet: Time. We would need time to experiment with integrating languages into our tooling, and we simply are too busy at the moment to do that…
Nice.
Our org pushes OO quite a bit, so I’d need to push for a change in development methodology. However, in practice we do something in the middle between OO and functional, and I’ve been pushing to go a bit more functional.
We have leeway here since we use microservices, so using Rust in just one part of the app wouldn’t be too disruptive. However, our teams haven’t specialized, so we’d need at least one person per team that’s comfortable with Rust.