Hacker News Reader

Comment by Cloudef | Hacker News Reader

It may replace some software, but it won't really lure many of the C / embedded developers. The problem is that rust developers miss the point of C. People who program with C want the bare minimum, they don't care about classes or other OOP features. If there was something that sort of grogs what C programmers want, it's probably zig-lang.

To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible. More data, less code.

View on HN

Putting on my embedded engineering hat, it's not that I wanted the bare minimum it's that I couldn't afford anything more than the bare minimum.

I couldn't afford abstractions, memory safety guarantees, algebraic data types, generics, pattern matching, thread data safety (at least in the context of interrupts). The languages that had these things were hulking languages with giant runtimes and exactly zero support for embedded development. Not to mention no vendor toolchains.

Rust supports all these things, with no allocator, no standard library, and often with zero additional cost -- in terms of compute and in terms of memory. Then, being built on LLVM means that the vendor toolchain support is quickly becoming a non-issue. I suspect we'll start to see more and more of Rust in embedded, but only time will tell.

And as others have called out, Rust has very few OOP features like an optional notion of a `self` on a function bound to a structure. There's no classes, no subclassing, no message passing, no inheritance at all (structure, interface or implementation), limited dynamic dispatch, no polymorphism.

> Rust has very few OOP features like an optional notion of a `self` on a function bound to a structure. There's no classes, no subclassing, no message passing, no inheritance at all (structure, interface or implementation), limited dynamic dispatch, no polymorphism.

As an embedded developer for a living, if you put it that way, then the first thing it comes to my mind is "so why should I bother learning Rust" for embedded.

Other than the usual "please consider UB and network/memory handling/security issues" (reasons that don't really affect me), so far nobody could provide a convincing answer.

It's not that the usual answer I get is wrong or invalid or doesn't have a point. But if I ask "ok, what else?" there is really little motivation for me to move on.

Someone once told me I'll become an outdated curmudgeon here on HN, but I think I'll be long gone before something truly deserves to replace C for embedded (and low level).

Personally, I always encourage people to learn new and (particularly) different languages from time to time and see what concepts and design patterns they can learn and take with them into their day to day. All I can say is give it a shot sometime and see what you think. Worst case you've learned something :)

> Someone once told me I'll become an outdated curmudgeon here on HN, but I think I'll be long gone before something truly deserves to replace C for embedded (and low level).

You (and I) may become an outdated curmudgeon before long, but it won't be because you refused to learn Rust haha.

> the first thing it comes to my mind is "so why should I bother learning Rust" for embedded.

Generics alone are a huge time saver compared to C, even if you use hacks like macros in the latter to do something similar already.

> C / embedded developers

Embedded developers use C because they have to, not typically because they want to. And they have to use C because of proprietary toolchains and existing libraries, among other similar reasons. Good reasons, sure, but not because C the language is so great.

> hand-crafted data structures [...] More data, less code

You're paying lip service to the principle of datastructures-over-algorithms, yet you're advocating for a language which has neither algebraic data types nor tuples? Come on. That's like praising functional programming but using Fortran.

Rust doesn’t have classes or indeed many traditional OOP features, and it has an extremely strong focus on data.

> To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible.

I wrote Monocypher in C for one reason: portability.

From a systems point of view, crypto libraries are trivial: you don't need any dependency, code is pathologically straight-line, there is no almost data structure to speak of beyond arrays of bytes and arrays of words.

Yet I can tell you that if not for portability, Rust would have been a better fit. So I could group buffers and their size in a single argument. So I could provide genuinely high-level interface. So I could use types to avoid silly mistakes and enforce some invariants. Portability won over all that goodness: worst case I can have a Rust wrapper. Heck, someone else already wrote one for me.

These zero-cost-abstraction languages don't pay much attention to binary code size. They can't compete with C in that regard. For the low-cost, high-volume embedded devices, code size relates to the unit cost, and thus the profit margin.

Just read this.

https://www.ecorax.net/as-above-so-below-1/

> To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible. More data, less code.

This. Even if it is less safe.

Reply on news.ycombinator.com