I am trying to migrate our embedded development from C to rust. But when I tried to "move things" I was given the comment below. I would like to have your comment, and wish to have a critical point of view on the subject:
《 I have been doing embedded C programming (and on desktop computers ranging from CPM, DOS, OS/2, WinNT etc) for more than 40 years now. In these 40 years, I have also used a lot of other languages (PL/M, Pascal, Modula 2, Comal, Occam, Assembler etc.), the only thing that has been constant over all these years is plain and simple C. There have been some additions to it over the years, but fundamentally it is the same as when I started with it late in the 1970’s. During all these years, I have seen zillions of different programming languages pop up, 99% of them has died again. Many of them claimed to be “the new embedded language” and so on. None of them were.
The only constant (embedded) programming language has been, and still is, C. ALL silicon providers today deliver their libraries and examples in C today as well as in 1970/80’s.
Now, I don’t say that there is not a better language than C, there most certainly is, but if you are looking at something that “covers it all”, is super-efficient and “hardware close”, C is the only answer in my opinion. 》
My point of view is that staying anchored so far in the past is not profitable for the developers (development environment, compilator performance/intelligence, ... ).
I also know that it is a change that will have a huge inertia, to have for example the chip provider to produce examples in rust.
But I believe it is sometimes necessary to "move things"!
Well, let me add my 2 cents here:
I do feel that Rust could be a great alternative for embedded programming. The reason for this, from my point of view, it is possible to write real hardware close stuff and even more important to me it is more memory safe to use Rust in the "right way", meaning avoiding unsafe code blocks. Especially in embedded systems the used system resources and memory should not be wasted or usage violated.
However, Rust is shining in the open source community and this also allows to be able to provide crates/libraries cross platform. From companies providing software and specially libraries for embedded system I'd expect they do want to keep this closed source. This is quite easy to manage with C as you could ship a library and only publish the open API using .h files to the community. Than it's easy to provide the examples in C as well.
I'd like to see in the near future that more and more developer and enthusiast that are open to try new ways of doing things differently proof that Rust is also a good fit for embedded development. And I'm also doing a lot embedded bare-metal Raspberry Pi things to learn Rust and also proof for myself that it is really an alternative.
From my last decade being a software consultant and developer I've seen that especially in this area - development - the major mud seems to be "never touch a running system" or "we fear the refactoring as we would like to secure the investment and keep the total cost of ownership low and the return of investment high.
That's just my personal view. However, the might be also never be something like "one size fits all" approaches within software development. From my experience also development languages exist to address quite specific problems and therefor I guess as many different problems that require software to solve them there will be always at least the same or a comparable amount of languages around to solve them.
I can tell a similar life story and come to a different conclusion:
I won't list all the architectures, languages, operating systems, hardware platforms and application areas I have worked on since 1980, that would be boring.
The only constant over the years is change itself. Languages, operating systems and architectures have come and gone. They continue to do so, witness the arrival of the RISC V architecture, the growing use of GPU's and CUDA in embedded systems and of course Rust.
It is true that C has been around and used throughout that time and will no doubt be in use for a long time to come. But it has not been exclusive of many other things and there is no logical reason that fact should dictate it's use forever. The quote sounds like a retired bookkeeper from the last years of the Roman Empire explaining how Roman numerals have been around for centuries and that there is no need for then new fangled zero or Arabic numerals.
As for silicon providers I will point out that both Intel and ARM are investing time in Rust. Perhaps it would be wise for the new generation to keep up with them.
It's not even true that ALL vendors provided libraries and examples in C in the 70's and 80's. I did not see any such thing until perhaps the late 80's.
Finally, evidence from those implementing embedded systems in Rust, including myself, would suggest it is a perfectly viable alternative to C and brings very desirable, long awaited, advantages.
Frankly, that quote shows signs of coming from a source that is out of touch with the past never mind the future.