Who is NOT moving from C/C++ to Rust?
There is a clear trend of companies interested in migrating existing C/C++ to Rust, with notable examples like Microsoft, ANSSI, DARPA, etc.
Do we also have examples of companies that, after thoughtful consideration, decided that this should NOT be pursued in the foreseeable future? (ie. next 10y)
Since we usually see pro-rust or neutral/maybe positioning (eg. Linux kernel), it would be interesting to know the counter arguments.
PS: In the context of large projects, with long-term support in mind, and that decided to stay on C/C++ specifically -- not that Rust isn't chosen but Zig/other is instead).
Best
10 comments
[ 2.3 ms ] story [ 39.6 ms ] threadEven using OO over plain C adds a huge amount of extra work already.
There is definitely interest in using Rust for safety critical work:
https://www.adacore.com/gnatpro-rust
https://ferrocene.dev/en/
I think it will definitely happen, but I am not sure how soon.
Projects like Ferrocene or GNAT Pro seem to indicate that's a possibility. (automotive gaining traction sort of paves the way to avionics/aerospace).
https://ferrocene.dev/en/ https://www.eenewseurope.com/en/first-rust-compiler-qualifie...
I don't know a lot about Rust myself, but the impression I get is that it is a bit less obviously deterministic than C.
Things boil down to (IMHO): - every requirement must be traceable to code - every line of code must fulfill a requirement - any dynamic behavior (for example heap allocation) must be proven to work under all circumstances
For example, neither PL from three mentioned ones can not do templates which are not a PITA when dealing with more than one data type. IMO (inspired by Lisp of course) this feature is more important than RAII or borrowing which effectively works only with tree-shaped data structures.
[1] http://250bpm.com/blog:4
My company works in high performance computing and there is no reason to move to Rust in the next 10 years.