Join us on Wednesday, May 12 at noon Pacific for the Embedded Rust Hack Chat with James Munns!
Programming languages, like fashion, are very much a matter of personal taste. Professional developers often don’t have much say in which language they’ll use for a given project, either for legacy or team reasons, but if they did have a choice, they’d probably choose the language that works best with the way they think. Some languages just “fit” different brains better than others, and when everything is in sync between language and developer, code just seems to flow effortlessly through the keyboard and onto the screen.
One language that consistently scores at the top of developers’ “most loved” lists is Rust. For a language that started as a personal project and has only existed for a little more than a decade, that’s really saying something. The emphasis Rust puts on safety and performance probably has a lot to do with that. And thanks to its safe concurrency, its memory safety, and its interoperability with C and other languages, Rust has made considerable in-roads with the embedded development community.
To learn more about Rust in embedded systems, James Munns will stop by the Hack Chat. James is an embedded systems engineer, with a history of working on software for a wide range of systems, including safety-critical avionics, and rapidly prototyped IoT systems. He’s a founding member of the Rust Embedded Working Group, as well as a founder of Ferrous Systems, a consultancy focused on systems development in Rust, with a specialty in embedded systems development. James also used to write for Hackaday, so he must be a pretty cool guy. So swing by the Hack Chat and find out where Rust might be able to help you out with your next embedded project.
Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 12 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Just my view from 20+ yrs of software development experience: The whole person-fits-language idea only holds in amateur circles or in very inexperienced devs with little to choose from.
In reality, and though some languages are indeed interchangeable, the stack and language “flavor” would be largely determined by the problem at hand. It has little to do with preferences.
However true that “if the only tool you have is a hammer…”, and even if you really love it, it is not technically sound to use PHP to fire the airbags in a car, nor plain C to power the CMS in your corporate website. You get the idea.
It’s probably the same as with amateur visual artists who develop a “style” as a shortcut for learning to draw and then justify all their faults or shortcomings as features of their style – since it’s simpler to learn a bag of tricks and stick to that.
I agree. I’ve been professionally programming since ’86. Always fit the language to the job. Not person-fit-language. In my current job, Python fits a lot of the applications I now need to write/maintain. But still use C/assembly on the SCADA RTU/IED front, and c/c++ and Fortran on the EMS (energy management system) side. Fit language to the job.
That said, there are languages that just don’t fit the person. For me it is languages like LISP. I’d not be in this career if Lisp was the language of choice… Nope., notta. Also don’t care for VB either…. Never willingly start a project in VB. But that isn’t a career killer if asked to maintain one.
I’ve learned to ‘really’ dislike applications where I have to ‘peel the onion’ to see what is going on. I been in places where by the time I get to the bottom, I’ve forgotten what I was looking for in the first place…. Been there…. In real-time I want to know exactly what is going on, so some languages are really unsuitable for this area of programming.
As for Rust. I’ve tried to like it. Even wrote a text game program with it to kick its wheels. But some how I feel, it is just one of those flash in the pan, trying to build a better mouse trap languages. It certainly didn’t fire me up as a ‘this is the language’ going forward…. In my opinion. To much ‘cargo’ on board :) maybe. ha.
It’s funny that you started off with “Always fit the language to the job”, and then you went off into “I wouldn’t ever use LISP” and then finally “I wouldn’t use RUST”.
If you really were “Always fit the language to the job”, wouldn’t you have just told us where you’d use LISP, and where you’d use RUST?
In the end, your reply betrayed your original proclamation.
Agreed. we all have prejudices based on our experiences and education. However just because I am not comfortable with a particular language, does not mean i do not appreciate their strengths (and weaknesses ) . For example despite using functional languages for a number of years, I still tend back to trend back to imperative languages
Saying that I can see the point or Rust. it ticks a number of boxes. Firstly the language is relative terse, and close to the metal, but provides the high level features such as variable immutability which makes writing parallel code far safer. It fills a niche between c and c++, and therefore could well become the C replacement in the long run. However a lot of it will depend on adoption and support.
I read it more as “fit the language to the job, then fit the person to the language”. You wouldn’t select a non-LISP-coder to code a LISP application.
ugh i hate the whole ‘arduino’ concept…when i’m doing embedded development, i want a handful of simple discrete tools, not some big all-encompassing environment that tries to obscure the details of the target. i mean, i feel the same way when doing pc development but the compromise is so different when you’re targetting an embedded project where you are gonna be coding ISRs, counting cycles, manually managing memory and concurrence, and so on.
i bring this up because rust went so far that i wasn’t even able to use it for PC development work (let alone willing). when i installed rust, it wouldn’t let me do anything without a huge automated dependencies system (cargo?) which, to that point (several years ago now) simply had not been ported to ARM (which was my laptop at the time). mozilla had a build system churning out daily builds for ARM but they were deeply broken and obviously had not been tested in some time.
i didn’t want to just give up so i tried to work through the bootstrap dependencies to build it myself. but cargo itself depends on cargo, and on dozens of other modules which each depended on dozens of other modules. because the dependency system is so integrated, people will pull in a new package just to avoid 10 lines of trivial code. reuse ad absurdum. not sure if anyone else wretches when i use the words “the perl CPAN Text::CSV module” but if you do then you know how it felt.
the funny thing is, i did eventually win and got a pidgin cargo running which i then used to build and install real cargo. but it was such a time-consuming experience just to get started…when i discovered the project i was looking at wouldn’t build (rust had changed too much in the six months since it was written). and when i went to fix it, i found out it was over-designed, exposing a vast wrapper API but only using about 10% of it. and then i looked at how the wrappers were implemented and i decided either this guy was a moron or rust’s OOP is aggressively bad (it was a manually-expanded 5-line template over hundreds of lines). peeling the onion of frustration was just too much and i threw in the towel.
it is the exact opposite of what i would accept in an embedded environment. i hope someone tells me i’m full of crap and cargo is optional.
Give or take, Cargo is both a package and build manager. C doesn’t have package management, and people use Make/Cmake/whatever for build management. Cargo’s job is to make management easier – bringing in other crates, autoresolving dependencies, and managing the rustc version.
If you’d rather go that way, the `rustc` compiler does work just fine standalone. It probably gets to be a headache on larger projects, but is really simple to use for simple compiles.
I’m on Arch Linux, and there’s a rustc package available. I switched to cargo since managing multiple rustc’s (x86 + ARM) is hard without it.
C doesn’t come with a package manager, but often Conan is used.
writing compilers is hard
Not really, i’ve written a few. It’s not really hard to create something that will solve a particular problem, and do it well enough to justify the effort.
It is hard to create a swiss army knife that solves enough problems for enough people, and does it well enough that it takes over the industry… and only half the challenges are technical :)
(I just noticed the Holub compiler design book is now available for free download… it was mandatory reading when I got started)
If compilers are so easy, why is it that C runs everywhere, and these other languages only run on large, popular platforms?
Perhaps by “not really” you actually mean, “Yes in practice, but you can write toy compilers easily.” Right?
I mean, writing compilers is hard, unless you claim that nothing is hard. But that’s not consistent with the consensus of what the word “hard” means.
time, effort, demand. Rust covers the majority of processor families, however there is limited person power out there and while the effort to write compilers is not hard, it is significant, especially if you factor in testing.
In some ways however compiled languages are harder than interpreted languages where the job is just to port the VM to the processor family, but what you gain there you lose in performance
really resent when one guy says “It’s not really hard to create something that will solve a particular problem, and do it well enough to justify the effort.” and the next reply uses the word “toy.”
If you’re looking for single words to describe a compiler that solves one problem well enough to justify the effort, the word is “niche”, not “toy.”
I’ve been playing with rust on STM32 micros for a about a year and a half now, and it absolutely rules. The tooling is in constant development, so I wouldn’t recommend embedded rust for production just yet (it’s very close though!)
Using the embedded-hal definitions for device driver libraries make them trivial to use across projects/MCUs. I think having a deep opensource registry of device drivers will be a huge draw to embedded rust in the future.
Ultimately though I think embedded rust adoption comes down to: Are you happy to write C++ for embedded devices? If yes, then seriously consider trying rust. If not? Stick with C with no love lost :)
When all this Rust hype started I looked at the language and was like “WTF, is this some obfuscated C contest?” Let me know, how it runs on PIC12F508.
well there is no reason why it cannot. Obviously initially the RUST compiler makers have concentrated on the major processing families, but because it compiles down to assembler it should run on anything C runs on. The advantage is that the language has high level support for some safety features. Whether they have much value for a uC is another question
Not really, i’ve written a few. It’s not really hard to create something that will solve a particular problem, and do it well enough to justify the effort.
It is hard to create a swiss army knife that solves enough problems for enough people, and does it well enough that it takes over the industry… and only half the challenges are technical :)
(I just noticed the Holub compiler design book is now available for free download… it was mandatory reading when I got started)