Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you Rust in embedded yet?

kazlauskas.me

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Should you Rust in embedded yet?

#101

Post by makapuf »

monocasa wrote: post #33
dmitrygr wrote: post #31

Earlier quoted context omitted.

It really depends how you use it. If you are approaching from the standpoint of "I am writing code on a microcontroller", which means no exceptions, no static initializers, probably no templates, definitely no rtti, then it will be all okay. If you approach it from the standpoint of "I'm just programming, how hard could it be? Let's just use std::", you're going to have a very bad time and very quickly. C++, when use…

Static initializers and templates are great in a deeply embedded context, IMO.

Constexpr init can also be great in that case To initialize rom with complex objects.

Re: Should you Rust in embedded yet?

#102

Post by Sylos »

bb88 wrote: post #12
keithnz wrote: post #8

I'm completely in this boat at the moment. We are doing a hardware refresh of our embedded platform and I'm looking at the feasability of using Rust. I'm at the point where I think it is close to being viable, but seems very young. Most likely we will go with a platform that can support rust, and write the low level modules with the intent of using rust, but not use Rust just yet, but do a side project to asseses the…

Keep in mind that at some level, something has to be unsafe, unless you've got hard mathematical proofs that your code works as compiled.

Doesn't mean you shouldn't try to lessen the amount of code that's unsafe. That way you have at least a fighting chance at getting your unsafe code bugfree.

Re: Should you Rust in embedded yet?

#103

Post by AnimalMuppet »

koffiezet wrote: post #87
atilaneves wrote: post #81

Earlier quoted context omitted.

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones. > you can actually figure out in your head what the assembly will look like I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do. And it's not…

Psychological ones? No, simply the lack of available reliable compilers for some platforms was my problem. I developed POS applications, where C++ would have worked fine, if we had a decent C++ compiler on every platform we wanted to support. Some platforms used GCC, but most used proprietary compilers - where C++ support was completely absent or very scetchy. When you can't use exceptions, the memory allocator is ab…

> Also, C++ uses a lot more memory...

Depends on how you use it. "If you don't use it, you don't pay for it" is the C++ philosophy. If you use it as "C with objects", it should use no more memory than C with structs. If you use it as "C with polymorphism", it should use no more memory than C with function pointers.

Re: Should you Rust in embedded yet?

#104

Post by wiremine »

bb88 wrote: post #10
wiremine wrote: post #2

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…

> Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. So one thing I noticed from the micropython world is that chip makers are not going to support micropython. But there are third party companies that are supporting python on specific microcontrollers. One problem the chip makers have right now is language frag. Rust is competing against go, python, kotlin…

Kotlin Native might have a chance, and it looks like they are targeting embedded. But the rest aren't good fits: Anything with a GC is a no-go for serious MCU development. You just can't optimize the code deep enough. Swift's reference count system might be interesting... would be curious if you could target Swift for something like a M4 or M3.

Rust is the only low level systems language that really has a chance to complete with C/C++ in the space: it's mature, has a great community that's sizable, etc.

(I'm talking about using Rust for professional embedded projects... I LOVE micropython as a hobby)

Re: Should you Rust in embedded yet?

#105

Post by petra »

wiremine wrote: post #5
eaurouge wrote: post #3

Earlier quoted context omitted.

Specifically what level of support are you expecting from ARM, ST or TI?

Ideally I'd like to see Rust used to ship in production systems. I do a lot of IoT, and I don't see any of my customers green-lighting Rust until the silicon guys say "yes, we'll support Rust" and provide official HALs and support.

What about vendors wrapping their HAL's to rust with bindgen(or an improved version) ? will that be enough ?

Re: Should you Rust in embedded yet?

#106

Post by s73v3r_ »

pknopf wrote: post #11
_sh wrote: post #9

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (t…

Why is C king? Why not C++? The difference is just a compiler, and you can use C in C++.

A lot of it is due to the fact that many of these chips use ancient compilers, so the C++ support isn't that good.

Re: Should you Rust in embedded yet?

#107

Post by bb88 »

wiremine wrote: post #104
bb88 wrote: post #10

Earlier quoted context omitted.

> Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. So one thing I noticed from the micropython world is that chip makers are not going to support micropython. But there are third party companies that are supporting python on specific microcontrollers. One problem the chip makers have right now is language frag. Rust is competing against go, python, kotlin…

Kotlin Native might have a chance, and it looks like they are targeting embedded. But the rest aren't good fits: Anything with a GC is a no-go for serious MCU development. You just can't optimize the code deep enough. Swift's reference count system might be interesting... would be curious if you could target Swift for something like a M4 or M3. Rust is the only low level systems language that really has a chance to c…

> Anything with a GC is a no-go for serious MCU development.

That's a really good point.

Edited to add:

But now that I think about it, Java was originally a micro controller language. Sun decided it was better for the enterprise.

https://en.wikipedia.org/wiki/Java_(programming_language)

I'm not sure if they included the GC in the original version or not.

Re: Should you Rust in embedded yet?

#108

Post by AnimalMuppet »

emilfihlman wrote: post #78
wiremine wrote: post #2

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to s…

"Vendor support" for programming tools is cancerous and hurts development. We need to actively push away from such idiocy.

You're a hardware vendor. You've created a new embedded CPU chip. Since it's new, gcc doesn't support it yet - and may never, if it gets no sales. But nobody's going to buy it if there isn't a C compiler for it. So you, the hardware vendor, kind of have to do vendor-supported programming tools, or your new chip will never sell.

So what's your alternative to vendor-supported tools? Only use the standard chips that are already supported? That doesn't sound like progress. Expect people to design in a chip where there are no tools? That's not going to fly. Expect gcc to support every brand-new chip, whether or not it has any sales? The gcc people seem unlikely to see it your way.

So, what is your alternative?

Re: Should you Rust in embedded yet?

#109

Post by bb88 »

pjmlp wrote: post #92
koffiezet wrote: post #87

Earlier quoted context omitted.

Psychological ones? No, simply the lack of available reliable compilers for some platforms was my problem. I developed POS applications, where C++ would have worked fine, if we had a decent C++ compiler on every platform we wanted to support. Some platforms used GCC, but most used proprietary compilers - where C++ support was completely absent or very scetchy. When you can't use exceptions, the memory allocator is ab…

Modern C++ does just fine on a Commodore C64. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE

Sad that it took C++ almost 40 years to get there.

Re: Should you Rust in embedded yet?

#110

Post by bb88 »

pjmlp wrote: post #55
bb88 wrote: post #18

Earlier quoted context omitted.

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing. No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.

Only when compiling without any kind of optimizations, nor using vector instructions. In any case, C++ is copy-paste compatible with 99% of C89. So same benefits apply when using that subset. It is plain language religion as observed at a few C++ conference talks.

I think you're not giving engineers enough credit here.

The world moved from C++ to Java on the enterprise side back in the late 1990's. Why? Java was arguably faster and easier to develop in, even though many thought (including me) that C++ was technically a better language.

Post reply on HN