Dilip 18 Dec 2020 ======================================================================== Discovering the appeal of Rust. I've been a C programmer for most of my career. It's still the best language for embedded development, and I don't think it's going to go away any time soon. A skilled C programmer will tell you that anything that can be built with software can be built with C. I lived this life and I continue to believe this. However, I've had an opportunity to see what the C++ world has to offer over the past year. What I've discovered is that the phrase "developer velocity" takes on a whole new meaning outside the pure C programming world. Writing a new application in C usually begins with creating a directory, setting up a makefile and a git repository. Then, the first things to do are always the same: 1. Implement a logging library 2. Implement some basic data structures - a doubly linked list is usually the tool of choice. 3. Implement the common maccros: -------------------------------------------------------------------------- | #define MIN(a, b) ... | | #define MAX(a, b) ... | | #define ARRAY_SIZE(arr) ... | -------------------------------------------------------------------------- Then, it's a scramble to get a reasonable write-compile-test loop that's sane. Following this is a long process of carefully building something that's stable, is fully tested and is polished enough for a release. At the end of this process, the developer or team of developers will have perfect knowledge of all aspects of the software they produced. Every file included in the makefile, every data structure, every branch or loop that's in the binary. Standard libraries and some OS provided libraries are the sole exception to this - however, C developers have confidence in these libraries after they have proved themselves over several decades in production-quality software. What I've discovered with C++ is that the language forces a different approach to software development - C++ pollutes the code base with a bunch of behavior that is not visible to the code reader. The careful code review instincts that a C programmer develops over time won't catch bugs caused by overloaded operators (who in their right minds would think it's a good idea to turn a "+" operator into a function call?), polymorphism (Oh - there's anther method that looks exactly like this method, but it takes one fewer argument and therefore has a subtly different behavior. Good luck at catching me in the code review!) and a list of language features so large that it's fair to assume that one isn't expected to know all the features of that language to write code in it. In exchange for accepting these shortcomings, C++ grants glorious developer velocity. The amount of work required to go from an empty directory to a prototype software product is easily an order of magnitude shorter, possibly even more that that. Yet, I'm extremely uneasy with C++. C is not a safe language, but we cope with C's shortcomings by knowing both the language and the software being developed down to the last semicolon. With C++, this can not be done. Further, C++ encourages quick and dirty coding - which is more prone to error than carefully hand rolling every structure and function. Here is where I see Rust's appeal. A language that provides the same developer velocity as C++, but also provides certain safety properties at compile time. Will it replace C? I don't think so - C++ couldn't replace C everywhere for specific reasons, I believe those same reasons apply to rust also. On a microcontroller with a few kilobytes of memory, or hundreds of kilobytes at most - that is expected to run for years while sipping tiny amounts of power from a puny battery, and work for years without any hope of receiving a software update - a C programmer finds comfort in knowing that every line of code that will execute has been put in there for a reason and has been put in there by someone who had all other pieces of code/software in their head. Everywhere else, Rust is probably a better option.