Context: A few people and I at my current company are into Rust. So far we mainly use
Python and Typescript. However in the mid- to long-term we might need languages/tools for
higher loads and some CPU intensive tasks.
Personally I would like to use Rust, however I am not so sure from a business perspective.
Onboard new developers to Rust takes time and effort and people change position, jump teams,
get sick etc. leading to some fluctuation in staff. You could make a case for Rust here if
we assume it saves time down the line due less bugs in production and easier reviews as
reviewers can relay certain compiler guarantees and focus more on the business logic.
The question is, do Rust tradeoffs make for a good business case or is it just wishfully
thinking.
Rust doesn't really have a business case outside of extremely niche things. Its still mostly an academic exercise, similar to what Haskell was/is. Even in performance or embedded devices, its not really preferred.<p>The issue with Rust is that most of the algorithms that you commonly write in code don't really benefit from memory safety that Rust offers, and not having to write explicit code in a language like Python is much simpler and faster.<p>As for performance stuff, its often much simpler to encapsulate the code that needs to run fast in a system library and interface to it through native bindings in higher level language.<p>Rust is good for writing native performant applications that need to run and not crash. For example, writing an autopilot/stabilizer for a drone - you need to have it be able to interface with other software, like motor controllers and data coming from the communication chip, at the same time while performing computation, storing stuff in memory, e.t.c. Rust is a very good choice for this because it will reduce the chance of errors due to memory conflicts.
> Onboard new developers to Rust takes time and effort<p>The number of Rust developers is increasing rapidly, so this won't always be the case, and it's likely one of the only reasons not to use Rust in many green field projects.<p>The rapid adoption of Rust is also a reason to use it. If you publish an open source project using Rust then you're more likely to get contributions than you would using another language.
It depends on your business context. Different business need different business cases. What is the bottleneck or priorities for the business context you operate in? Engineering decisions that produce the best business outcomes for a pre product-market fit saas business in a low-risk domain might be regarded as criminally negligent for another business that ships medical devices.<p>Some other things to consider: How much does quality matter? What is the cost to the business, and to customers, of shipping a defect? How much would it be worth to the business increase the effectiveness of QA? How important is the ability to rapidly deliver low effort prototypes, perhaps using low or moderately skilled staff? Is the business focused around a particular domain -- how mature is the library support for that domain? Does the business already have substantial expertise with a particular technology?