Hacker News Reader

Comment by _bxg1 | Hacker News Reader

I hated using C/C++ in college because of all the arcane runtime errors and how hard they could be to debug, as well as the finicky tooling/library landscape, the mental overhead of object lifetime management, etc. Coming back around, Rust has given me my first opportunity to really appreciate and enjoy the more gratifying aspects of lower-level programming.

View on HN

Well it's exhausting to keep hearing the same old C/C++/Rust/Zig anecdotal testimonials of the day which might easily sway the decision for some but may bring misery for others as we are now starting to get credible alternatives in low-level programming.

Hence this, from the perspective of a typical embedded developer shop across the street with a medium sized team of 25+ engineers, would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future?

The choice is yours.

This comment reminds me of what Java and PHP devs were telling me about Merb / Rails in 2008. I'm not saying it's going to go the same way, but I'd bet rust continues to gain traction to the point of escape velocity in embedded systems.

Embedded Systems is considerably more conservative than web development. For example, many greenfield projects are still C over C++. And most new C projects are probably C99 instead of C11.

But yes, I believe Rust will continue to make progress and pick up pace. But it will be a slow process. And C is not going away anytime soon.

C11 didn't change much for uniprocessors iirc.

I think you overestimate the difficulty in "getting used to" something new when it comes to a PL (and rust, even though it has a bit of a learning curve for OOP folks).

I don't want to use C/C++ for embedded projects in the same way that I don't want to use a hand drill when I have a nice corded Milwaukee power drill on the workbench.

>C/C++/Rust/Zig

You can now add Zen to that list, seems to be gaining from traction in the Japanese embedded programming community.

Zen appears to be a fork of Zig.

Zen is just a copy-paste of Zig with cringy people and marketing on top, it's not a real language.

Zen is sponsored by a Japanese company which also happens to be sponsoring the top contributors in Zig.

As with all open source project you cant please everyone, and if you dont like it you can always fork it and make your own version. Which is exactly what they did.

As the CTO of a IoT sensor manufacturer doing a new project recently, I chose C for firmware over C++ and Rust (and Nim and Zig). C++, Rust etc would be technically more suitable languages. But it is just much easier to get a hold of competent people for firmware development in C than C++, and certainly than Rust. Both from microcontroller vendors, third-party vendors, development houses, independent consultants and new hires. If someone know microcontroller firmware development, they generally know C. Sometimes something else in addition, but always C.

If such a large number of JavaScript and Ruby devs could learn Rust relatively quickly[0], I'm hoping that a firmware dev could as well. The only semi-hard concept about Rust is lifetimes, and that's getting much easier now.

I mean, if you're not allocating to the heap, Rust memory management is not as useful, I concede. But once you learn to properly model data using algebraic data types (in Rust: enums and tuples), it's a huge, huge gamechanger in how you write programs. You can literally make it impossible to represent illegal states, thus saving massive amounts of error handling[1]. Functional devs have been enjoying this for decades, and now it's available to embedded world via Rust.

0. Seriously, a huge number of active Rust devs come from those communities. Even a significant number of Rust compiler devs come from Ruby and JavaScript backgrounds.

1. Yes, with some clever techniques, this is also possible - to a certain extent - in languages without ADTs, but only to a very limited extent. It becomes simple and natural with ADTs

For me Rust keeps the perfect balance between having all these awesome functional concepts but still be a language that works on real world state problems. Don’t get me wrong. I like Haskells Monads etc. But they try to hide the fact that we have state and all it’s wonderful side effects ;). Rust embraces state but with a clever system that feels always one step ahead of you. I also think a paradigm shift will happen when it comes to c. Yes it is used everywhere. Yes you get more developers now. Yes it has more libraries etc. But this was also true for the languages that where used before c. And I think Rust also has the chance to topple over JS in the web world. Lets see. I enjoy Rust at the moment very much and play around with it in all kinds of fields. It is already my number one language for command line utilities :)

It's hard to even convince most embedded C developers to try even a small subset of C++. A language like Rust is waaaaaay out of their comfort zone, and doesn't address any of their perceived problems (it shouldn't be, but this is how a large fraction will approach it: they would likely not even give it a fair chance due to the mode in which they operate).

I take the standard of tomorrow any day. Or at least would dare to experiment with it more with putting a small team to make a module with it. Rust has enough steam now, it would be irresponsible to bet against it.

I think one can both be excited about Rust and acknowledge that for most projects C is still the way to go.

The libraries, communities, compilers, vendor support, ...etc. is much more mature on the C side of things and will remain that way for a while.

At the same time, Rust is getting to the point where early adopters can start using it for their projects. Those are the people who will make Rust a full class option in the future.

Rust can interoperate with C libraries, it's a pretty substantial part of its value proposition. At the same time, it's true that C has way better compiler support for weird embedded targets, and it's also a comparatively mature language that's not going to change much over the years, with a vendor-independent standard definition. For some projects, these things might be important.

> Rust can interoperate with C libraries

True, but speaking as an embedded developer and Rust fan: embedded C libraries just love their #defines in public APIs. This makes interfacing with them from anything but C or C++ more cumbersome, because you can't just declare "extern" functions, you also have to translate the #define macros, which are sometimes non-trivial.

> would you rather adopt a accepted bad standard known and used across the industry or a new non-standard alternative which will require 'getting used to' by all engineers but comes with a risk of it being either suitable or unsuitable in the future?

Whichever one works with the hardware? >.> I don't think embedded folks are too used to having choices, usually we just take whatever toolchain the chip manufacturer gives us, so when there's a second option it's scary and strange.

And maybe the parent was talking about their experience working in a really small team, or on small embedded components of a larger system, or on hobby projects, and has entirely different considerations. Someone saying "I enjoy using Rust for this" does not mean "everyone has to use Rust now".

Like the article is exhausting? Or the anecdotes about Rust in the comments on an article... about Rust?

That's the same kind of choice than the one to move from asm to C a few decades ago. Of course, there's many situations where switching to the new tech isn't worth it, but in the long run it will become a more and more obvious choice (assuming the language takes off, the ecosystem will mature and the number of developers will rise).

Reply on news.ycombinator.com