Embedded Rust in Production?

>Only the author "knew" Rust [...] because the dev wanted to learn Rust

Many such cases. Recipe for disaster.

a.k.a. "resume-driven development"

I think the rule of thumb should be that if you wouldn’t write aomething in C++, then you shouldn’t use Rust.

Typically, devs polishing their resume instead of prioritising business metrics probably means the overall org is on the down slope.

Perfectly normal for people to want to develop their skills and to enhance their value.

The thing is that this is not a developer's decision, this is a management decision. The developer might pitch for Rust or even start developing in Rust but if that is not right for the org then their manager should say 'no'.

So ultimately this is a red flag about management.

Or the dev wants more money

That's a horrible rule of thumb, because C++ adds a ton of complexity with little reward except for speed. Rust adds less complexity (still a lot ofc), but it also gives you awesome tooling and dependency management (much better than python for example), and and extemely powerful typesystem and functional programming features, that make writing correct code extremely easy.

Rust is a complex but overall good language for writing solid software, C++ is making a deal with the devil in exchange for speed.

If a garbage collected language can easily do the job, choose the garbage collected language. I like Rust, but it is NOT the fastest language to develop in.

Typescript, Python, Go, Swift, and even Bash depending on the situation are all quicker to code in than Rust.

If any of those languages are inadequate for the requirements whether they be memory-bound, CPU-bound, or sensitive to gc pauses, Rust is an excellent option that is far superior to C++ in 2024 and beyond.

The notion of "one true language" has always been and will always remain a fool's errand.

You missed the point of the rule of thumb. Maybe rephrasing it as if 15 years ago you would have written it in C++ would help.

Nope. C++ has mostly downsides, Rust has significant upsides.

A good rule of thumb would be: is correctness and code confidence more important than learning curve and compile times? If so Rust, otherwise JS or Python (with possibly parts in Rust).

I write most of my stuff in a combination of Python, JS/TS and Rust these days with some form of Interop between them. I.e. mostly Python Marimo notebook with JS visualisations, and PyO3 Rust bindings.

Tbh I don't find myself to be "slow" in rust. Sure for quick exploratory stuff the notebook-environment and introspection capabilities of a dynamic language are definitely nice (e.g. when taking apart some unknown JSON data format), but especially when it comes to complex logic and refactorings Rusts type system is really making a big positive impact on productivity.

Sure TypeScripts type system is also powerful, but Rust is consistently better at infering types from closures and function calls, and the existing types and tooling story is miles ahead of TS. (and I've never encountered an easier to setup/use model checking language integration than Kani)

For one-offs where correctness doesn't matter, sure throw $SCRIPTING_LANG at it. But once you want correct software, I'd still choose Rust in a heartbeat.

Slightly disagree.

Needing the managers permission is more of a "wartime" mode.

For peacetime the management should set a culture of peer review and data and logic driven discussion. The culture would ideally have a Rust lover sit there and think "would love to do this in Rust but...." because they know their peers will be affected by this decision.

The problem with management approval required is it usually meams no or bias towards management pressures. A management veto that is occasionally used may be better.

Disclosure: not a Rust programmer but pretty neutral on it. It is on my radar if I get a problem Node or Go can't solve.

I'd agree with ndndjdjdn in that management getting involved should be the last resort, and potentially only to veto a very bad decision.

I think the main issue here is having a single dev going for Rust. Ideally someone interested in a new technology would pitch it to the team, and they'd discuss if they want to have a shot a it and if they can justify the investment for the whole team. That's where a tech that doesn't fit would be discussed and rejected, potentially with a proposition for a better option that devs are also interested in.

Even if it starts with just a prototype, if it touches production the other members of the team should be able to review it and maintain if needed.

That's this whole bit missing, and the team looking at it as a thing of life, that makes me think they're not focused on pushing things forward anymore at an org level.

C++ is incredibly fast and still the language of choice for a lot if not most computing intensive tasks.

Pretty much it.

See my initial: > C++ is making a deal with the devil in exchange for speed.

That really doesn't matter when the price of the devil's deal is cheap.

ie: security is rarely a problem when selling software