[muffles]

What is the implication of this to embedded software platforms like Xilinx VITIS or TI's Code Composer Studio? Both tools are based on C/C++ so why would these platforms not have switched to C# or Rust earlier? Sorry for the simple question as Im a simple hardware guy but do you see a scenario where future platforms of these tools are based on Rust?

[nicoburns]

I think embedded software will likely switch to Rust (or other non-C/C++ languages) eventually. But that transition will be behind the transition for PC/server software by probably 10 years, partly because these indeustries are just slower to change, partly because support for these kind of environments in languages like Rust isn't as mature as support for more "full OS" environments, partly because these environments are often dependent on proprietary compilers provided by vendors and getting these vendors to ship Rust compilers is going to be a slow uphill battle.

In some ways Rust is (or will be) particularly well suited to these environments. They're hard to debug so the compile-time constraints are particularly helpful. Features like async/await are perfect for modelling interactions with hardware peripherals, etc. But there are still a lot of rough edges. Most embedded development with Rust is still relying on unstable nightly features (particularly more advanced const evaluation). Although the recent stabilisation of GATs helps a lot.

[qsort]

Sic rebus stantibus, neither transition is realistic without enormous and painful investments.

Basically every single piece of software that matters is a C library or is exposed through a C API, because that's what other languages hook into, including Rust.

Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is.

Using memory safe languages when you can is good advice, but it's kind of complicated to get to a point where everything is guaranteed safe.

[nicoburns]

> neither transition is realistic without enormous and painful investments

I don't disagree, and for that reason the transition will be slow, but I still think it will happen. The benefits are too great to ignore, or they eventually will be. Nobody's going to want to use insecure foundational libraries once secure ones are available. And they're already being written.

> Heck, right this second I'm working on a piece of software that needs to talk to Java and Python simultaneously, so C++ with extern C it is.

For what it's worth, Rust is entirely viable (and arguably easier than C++) in this space right now. It's also using extern C under the hood, but there are libraries like "pyo3" and "jni" which will deal with the unsafety for you and provide you with higher-level bindings. In practice you don't lost much safety using this approach.

[kaba0]

Well, it could be written in Java, so Java-Java communication is trivial, and you could use something like protobuf to communicate between java-python. Or just some fixed binary layout.

Or even GraalVM which is polyglot between the two languages and can even optimize across language boundaries.

[bluGill]

Depends, i know one company that spent billions swithicg to memory safe stuff, but after a few years an experienced team did a project in both the memory safe new stuff and in parallel the same in C. The C code was done in a week, the new stuff 3 months. They are back to C for everything and the people pushing memory safety are gone.

The right tools mater. The memory safe stuff above was autosar, so not something often discussed here. Rust is getting interest from the above team but after the above burn they are slow to try new things.

[pencilguin]

We may presume the Modern C++ version would have been done even faster, then, and without memory faults.

[bluGill]

The team in question had decades of c experience, and was doing all new stuff (maybe half of all work?) In autosar. I was working with them on an unrelated C++ project and I can assure you the C++ they write was not very good since the only C++ stuff was things they didn't want to do.

[RealityVoid]

I work with AUTOSAR. I am fairly confident that AUTOSAR itself is the problem and not representative of the productivity you would gain from memory safe stuff. I can also say that the AUTOSAR stacks themselves offer no memory guarantee and have seen way too many bugs in those stacks to have any sort of faith in them.

[pencilguin]

We may presume that, coming in C++, competent modern C++ developers could be found, unlike for immature languages.

Building everything performance-critical with immature languages is not a viable alternative. But building with modern C++ is one.

[rightbyte]

I don't see how you mix memory safety with DSP programming. You gonna handle interrupts, DMA, cache etc automagically?