Item — HN Reader

> Rust is the new kid on the block.

> It supports a wide variety of platforms,

> and might even run on that microcontroller

> you think can’t run anything but C.

Hahaha.

Oh, you're serious...let me laugh harder...

When the rust compiler can produce code that runs on my micro with harvard architecture, 14-bit instruction words, and 64 bytes (not megabytes or kilobytes) of RAM, we can talk.

EDIT: loving the downvotes. Keep them coming! Because nothing says "civilized debate" like quiet underhanded unexplained disagreement :)

6 comments

Downvoted because you took a simple statement to extreme and then argued with that. The author said it supports many platforms - and it does. It might support your microcontroller - and it might. But of course you can find counter examples - and it doesn't change anything. There are also platforms you can't program in C, but you're not making fun of that for some reason?

You will also never have a memory safety issue on that processor because in that environment using malloc() is already considered a sin of the highest degree.

I wrote a chess program that ran on a PIC 16 series with 176 bytes of RAM and I got 5 levels of look-ahead with a compiler that didn't support recursion. No dynamic allocation anywhere.

I laugh when people claim a Raspberry Pi 3 is an "embedded system". Sure you can embed it in something, but it's got an ocean of resources compared to most.

Keep in mind that there's a middle ground here though. ARM 32bit micros still have basically no support from Rust et al but often have enough resources (Cortex M7 anyone?) to do things where it would be nice to have memory safe dynamic allocation. Programmers often have to resort to convoluted static data structures for some tasks where dynamic allocation would be useful and don't get me started on the NXP LPC-like chips that have two cores with shared regions.

How do you mean 32-bit ARM doesn’t have Rust support? See e.g. https://mobile.twitter.com/japaricious/status/84569793557265...

“Cortex-M3 micro (no FPU) @ 8MHz”

Currently the only way to use it is via zinc which only supports a few chips and the thumb eabi which is currently in "tier 3" support with no provided binaries or assurances of stability.

Basically, there are experimental ways to get it to work, but it's a huge ways away from being useful in a production environment.

https://github.com/hackndev/zinc https://forge.rust-lang.org/platform-support.html

If you'd like to start a substantive discussion, you have to offer the community a comment in the same spirit.

Additionally:

> Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

https://news.ycombinator.com/newsguidelines.html

> When the rust compiler can produce code that runs on my micro with harvard architecture, 14-bit instruction words, and 64 bytes (not megabytes or kilobytes) of RAM, we can talk.

Pretty irrelevant in this case because your micro doesn't matter for the type of code we talk here. I doubt things the size of libcurl, openssl or anything like that will run on this thing.

I doubt you'd be running Curl on that microcontroller.

Port LLVM to it, you're halfway there.

Such a restricted machine unfortunately is not amenable to any abstraction and I have no idea what such bad hardware would be used for. Nor why.

Tiny microcontrollers are used all over the place. They're useful in things like appliances and simple peripherals.

I'm guessing that the other comment is referring to PIC microcontrollers. Over a billion such microcontrollers are sold every year. Not all of them are that limited, but many are.

And they are amenable to the abstraction of C. That's kind of the whole point of that comment.

The world of computing is far larger than PCs and smartphones. One could make a convincing argument that those are a small minority, in fact.

> And they are amenable to the abstraction of C. That's kind of the whole point of that comment.

Well, that's sort of the problem, right? C was made so portable (because, admittedly at the time of development hardware was less uniform) that a lot of assumptions we take for granted are actually undefined, because you can't make those assumptions about the underlying hardware. What makes C usable and useful on these architectures is the same thing that causes problems for the other 99.9% of people programming in it.

Should a language with obvious shortcomings in the name of portability be one of the de-facto standard languages for all types of library development? Do i even trust a crypto or XML parser library written in C on a platform with a non "standard" word or byte sizes that wasn't developed specifically for that architecture, or those constraints?

> The world of computing is far larger than PCs and smartphones. One could make a convincing argument that those are a small minority, in fact.

As a question of where to optimize, I would say it pays to get a much safer language on these devices, both because it would prevent crashes, bugs and security problems, and because (I think?) far less people are responsible for writing the code, so a little extra work on their part pays of more overall).

I think C is as prominent as it is today because of how history played out, not necessarily because of its inherent merits.

But, to be fair, dynamic memory management is rarely used in microcontroller programming. Additionally, it's much easier in such a restricted environment to test the machine against every possible input (or a very representative sample). This explains the relative paucity of memory safety bugs in these environments.

They're not that amenable to the abstraction of C. Companies have managed to create C compilers for PICs anyway because there's a market for them, but they have - amongst other problematic features - bank switching for RAM and register access, extremely limited support for indirect addressing, no hardware support for function pointers, a hardware stack with limited depth that cannot be accessed directly, only implicitly via call and return instructions. Someone elsewhere in the thread mentioned using a compiler that didn't support recursion; that's probably because there's no easy way of supporting stack variables on most PICs.

>I have no idea what such bad hardware would be used for. Nor why.

You would use it for places where the uC is cheaper than a few transistors or flip-flops, for example to flash lights in a pattern. Also when you need extremely low power consumption, like a digital watch or BTLE beacon.

There are uCs in everything these days.

https://en.wikipedia.org/wiki/PIC_microcontroller

Incredibly common chips, less so today, but historically they were all over the place. Looking at Wikipedia, it seems the 14bit instruction set PIC had a whopping 128 bytes of memory.

For managing a bunch of toggle switches or dials with 8 positions, I imagine that was more than enough.

> Such a restricted machine unfortunately is not amenable to any abstraction

I can't tell if you're using hyperbole, or if you mean "any abstraction" literally.

If you mean it literally, we should probably discuss that.