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.

[–] sugar_in_your_tea@sh.itjust.works 5 points 11 months ago* (last edited 11 months ago) (1 children)

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.

[–] soulsource@discuss.tchncs.de 4 points 11 months ago (1 children)

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.

[–] sugar_in_your_tea@sh.itjust.works 5 points 11 months ago* (last edited 11 months ago) (1 children)

C++

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

[–] soulsource@discuss.tchncs.de 2 points 10 months ago (1 children)

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

[–] sugar_in_your_tea@sh.itjust.works 2 points 10 months ago

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.

[–] GarlicToast@programming.dev 1 points 10 months ago

Got the OK to try Rust as a Python replacement for a small internal tool when we maxed the system's RAM. The Rust version took 1/10 the memory.

After after a few more internal successful changes to Rust, we now have one public tool developed in Rust.

The language is amazimg. Used to be C for performance, Python for the rest. No more C for us. We even use Python less.