Dilip
<
[email protected]> 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.