[fullstop]

I keep seeing more and more news about Rust, and figure that perhaps it is time that I learn something new.

99% of my development work these days is C with the target being Linux/ARM with a small-ish memory model. Think 64 or 128MB of DDR. Does this fit within Rust's world?

I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are and the "cost of protection"? For reference, using rustc version 1.41.0, the stripped binary was 199KiB and the same thing in C (gcc 9.3) was 15KiB.

[steveklabnik]

The smallest Rust binary ever produced was 145 bytes. https://github.com/tormol/tiny-rust-executable

That is a bit extreme but it demonstrates the lower bound.

There's a lot of things you can do to drop sizes, depending on the specifics of what you're doing and the tradeoffs you want to make.

Architecture support is where stuff gets tougher than size, to be honest. ARM stuff is well supported though, and is only going to get better in the future. The sort of default "get started" board is the STM32F4 discovery, which has 1 meg of flash and 192k of RAM. Seems like you're well above that.

[hellofunk]

> ARM stuff is well supported though

FYI Rust (and Go) currently don’t work on the new Apple ARM macs.

https://news.ycombinator.com/item?id=23856806

[steveklabnik]

That is not entirely correct for Rust. I know because I helped a friend of mine debug the porting process. (Apple did not see fit to give me access to the hardware, alas.)

https://github.com/rust-lang/rust/issues/73908 has the full details.

(Also, not to be super pedantic, but this (among other things) is partially why I said "and is only going to get better in the future," that is, the support is generally good (I know, I am literally doing some of that in another tab right now) but not flawless.)

[hellofunk]

Very interesting, thanks for the link!

[steveklabnik]

You're welcome! And I'm sorry you're downvoted, I think that's a little overly harsh. Had I not known, that would have been helpful.

[oblio]

That platform is not even out yet. Outside of Apple's stuff, I doubt any ecosystem supports it.

Some probably won't support it years after it's available for actual commercial products...

[hellofunk]

No need to yell, it’s a relevant point to make since we’re talking about ARM.

Not sure also what you mean by giving it a rest, this is the first time I’ve made a comment on this point.

Update: thanks for editing your comment to be less offensive.

[oblio]

I've removed the yelling :-)

Someone else was saying the same thing in the comment you linked. I'll summarize it as:

"Rust takes time to port to a platform which is not even commercially available".

[kibwen]

There are some people who have already gotten Rust to work (with caveats) on Apple silicon: https://twitter.com/JakeGoulding/status/1279207843711811585

[bestouff]

Yes there's a fixed cost because of the std library, panics unwinding code (i.e. clean recovery instead of aborting when something goes wrong), and the tendency to statically compile everything in adds some more, but in embedded context (a.k.a. "no_std") you can observe C and Rust code are very comparable.

Especially in your case you'll find Rust to be a joy to use: you'll have way more confidence in your code being able to run for months without segfaults or memory leaks. And if you have a good understanding of the C memory model using Rust will be a breeze.

[pitaj]

A significant portion of the size is formatting and panic unwinding code. Some of this can be reduced by using `panic=abort` but it is a known issue.

Worth noting that a lot of the code size is a constant addition that won't really scale with your program code.

[fullstop]

Thanks, I'll take a look at this!

[nicoburns]

If you're running Linux with MBs of RAM, then you're well within Rust's comfort zone. If you're on embedded ARM (cortex-M) with KBs RAM, then Rust will be really nice and it does work today, but there's still a few missing features to make it nice to use.

[jwr]

Your devices are huge compared to what I use: ARM Cortex M0+ and M4 microcontrollers with anywhere from 8kB to 1MB of flash, and 4kB-128kB of RAM.

I really hope that more enlightened vendors (hi Nordic Semiconductor) will start supporting Rust on their platforms.

[riquito]

The following is a very good resource, going from safe/practical ways to reduce the size (like `strip`) to more advanced and unpractical builds (up to 8KiB hello world, removing... a lot).

https://github.com/johnthagen/min-sized-rust

[zozbot234]

> I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are and the "cost of protection"?

Relevant: https://news.ycombinator.com/item?id=23496107

[bschwindHN]

Some simple firmware I'm writing (controls some lights, takes rotary encoder input, prints stuff on serial) is currently 8K. It's written in Rust and targets the stm32f1xx and stm32f4xx chips.

[jefftime]

I've been playing with Rust myself in my free time, and if you use Rust with the standard library a stripped executable should be smaller and more comparable to C than what you're seeing with the standard library included. Depending on your use case, you might be able to get away with just using the core library

[jefftime]

Ah, meant to say "without the standard library." My bad

[maxkrieger]

Dunno if it's apples and oranges for you, but I've seen Zig [0] being thrown around here previously as a "safer" embedded C alternative, albeit more minimal than Rust. May be worth comparing (I haven't tried either language).

[0] https://ziglang.org/

[PudgePacket]

Rust also statically links by default.