Ask HN: Business case for Rust outside high performance or embedded devices? | Hacker News Reader

Ask HN: Business case for Rust outside high performance or embedded devices?

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.

View on HN

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.

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.

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.

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.

Thank you for your input. I like Rust a lot but I am also aware that I might see in trough pink glasses. Could you make the case for Rust as i.e. a backend service due to increased correctness and thus saved time in debugging and maintenance?

You have to think about what correctness means. Rust is designed for memory safety, i.e within a program memory space, it ensures that when something writes to a memory its allowed to. Most of the code in your program won't benefit from this, especially if using standard libraries for things.

For other things, like data manipulation, its no more correct than any other language. It also won't help you with algorithmic errors that are language independent.

> Onboard new developers to Rust takes time and effort

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.

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's also the case that it's a language people want to learn. For better or worse, you'll get candidates who want to use it. C is probably still better for performance due to compiler maturity, but the proportion of devs who say "I want to code more C" to "I want to code more or start coding in Rust" is likely not great.

A year or two from now the investment will probably look pretty good.

I am a bit sceptical when it comes to acutal adoption of Rust. On github language stats the number of PR & pushes seems to be more or less steady over time.

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.

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?

Making a good business case is something I am still learning. Here we were wondering, from a pure software-dev point, if we could make a case for Rust, independent of the use case by trading ramp up time for time spent for debugging and maintenance. The question here if Rust really saves time down the line or not compared to other languages.

Reply on news.ycombinator.com