It's in the more detailed roadmap RFC under the embedded WG:

https://github.com/rust-lang/rfcs/blob/master/text/2657-road...

Which itself is hidden behind having a dropbox account: https://paper.dropbox.com/doc/ZmUYvRp4PjX1jqq6LSxcZ

Can anyone copy/paste it somewhere else ?

Here you go! https://rentry.co/wyf5v

Several of these items are very relevant for the embedded world (custom registries, custom allocators, unsafe code guidelines, etc.). They just didn’t use the word “embed” in this short post.

Do you know how difficult it is to write a position-independent blob that runs all by itself? Consider something like a boot loader or kernel, starting from a random location in memory. Can it run without needing assembly language?

For example, C can often do this. You ask the linker to put a particular function first and to make everything position-independent. There can be some problems with the GNU toolchain stubbornly insisting on making a GOT, but the language is otherwise fully capable.

It's very easy, in fact. Because you don't use the stdlib, it requires handling some language items (the equivalent of having to write your own _start routine, for example). You set up vector tables just like normal, and you decorate things to tell the linker where to put them.

The canonical example is https://github.com/rust-embedded/cortex-m-rt if you want to get into the guts of how it works. For a more user-focused overview, check out https://github.com/rust-embedded/cortex-m-quickstart, which is a good starting point from which to drill down.

"Embedded and IoT is about to get a lot bigger"

I'm curious what makes you think that? Culturally, I feel like there's been some general backlash to the gratuitous IoT-ification of every aspect of our lives, from a privacy perspective, a fragility perspective, and a "using apps to control everything isn't actually convenient" perspective: https://twitter.com/internetofshit

Microsoft just purchased TheeadX. Amazon purchased FreeRTOS. Intel, Nordic and others are dumping time into Zepher.

Those are three RTOSes specifically being designed to run IoT endpoints. I’m working with FreeRTOS and AWS IoT right now, and can tell you Amazon is taking it pretty seriously.

I think 90% of IoT are devices that don’t need to be connected - no doubt. But mine does and sometimes it’s there are pretty awesome use cases for it.

If Rust wants to make it to C-replacement, they should be bringing over backwards to get away from DoItAllYourself IDEs and into commercial products like Keil, IAR, Segger, Attolic, etc. I promise when E+++ or Swifterz or C% or whatever crazy new hotness shows up, Rust will be the hardest hit language to lose its enthusiasts.

I don't know a bunch about it, but Azure IoT Edge (by Microsoft, as you'd expect) has a significant amount of Rust. I'm not sure if it's something that's directly comparable, but is at least somewhat similar.

Yet they decided to go with C for Azure Sphere, in spite of the whole security history they are trying to sell around it.

https://social.msdn.microsoft.com/Forums/en-US/72ae0354-63eb...

The pearl is the typical set of recomendations of how good C developers are expected to write unsafe secure code.

When you read the marketing materials of Azure Sphere, it is all about security everywhere.

Another proof that while we need safer languages, we also need to improve C's security story, as this will keep on happening anyway.

Well, if they rewrite ThreadX in Rust, let me know!! :)

Interesting. I didn't know about all that.

The cynic in me thinks all these companies are just continuing to push on something people don't want because it's a gold-mine of data collection opportunities. The optimist wonders if IoT will settle down and mature into spaces where it's actually useful, and "90%...are devices that don’t need to be connected". We'll see, I suppose.

>The cynic in me thinks all these companies are just continuing to push on something people don't want because it's a gold-mine of data collection opportunities.

No doubt! And the dumbest of IoT products like “connected mattresses” should prove that.

In my own defense, I’m doing a LOT of work to never ask the user for an account or password, never logging personal data, just shipping a nice device that does a helpful thing. But.... there is an obvious temptation to RECORD IT ALL (figure out what to do with it later!), but I’d be a massive hypocrite.

For me it’ll be a selling point that we don’t care who you are just that you have a device and want to do a thing.

I think Rust can help securing IoT devices.

The problem isn't (primarily) security. And in the cases where security is the concern, like electronic door locks, the problems usually come from sheer laziness; like giving every device the same unchangeable PIN, or sending things over the air in plaintext. Things that have nothing to do with the language.

Well, at least those who do implement security protocols correctly do not need to worry as much about random memory safety related exploit chains.

Having done a lot of embedded work in both C and assembler, I'm really excited by the prospect of a type-safe, memory safe language with zero-cost abstractions that can compile down to [more or less] the same machine code that C would produce.

For those interested, check out Jorge Aparicio's (japaric) RTFM2 series:

http://blog.japaric.io/rtfm-v2/

(in particular the sections titled "Preemption" and "Critical sections and Threshold")

Me too. But until I see Segger/Rowley or any of the second tier IDEs below Keil and IAR pushing first party support, I can’t even consider it.

It’s a big leap from hobbiest to commercial with embedded.

If I was part of the Rust group I’d be directly real resources into real embedded projects. You check Cargo for embedded now and might find a couple unsupported header files for different micros.

It’s going to be a long time at this pace.

> Nope, well... Maybe next year! I've been eyeing Rust for embedded but until there are major players shipping IDEs that natively support it

It is not obvious to me what more can the Rust team do here; it would seem like the ball is in the vendors court (or whoever counts as "major player"). Plenty of the groundwork has been already accomplished, and the embed-wg continues on their good work but they can't just conjure vendor support out of thin air

I’m not saying hookers and blow... but I am saying the Rust group needs to be actively courting professional/commercial IDEs, and more so developing in such a way that an IDE could bring in the Rust compiler.

Maybe it’s too early for that. Maybe it’s just the right time.

> developing in such a way that an IDE could bring in the Rust compiler

They are doing exactly that if you look at the "Compiler" section of the roadmap[1].

> One project worth calling out in more detail is the RLS 2.0 effort. The existing RLS, while functional, was never deeply integrated into rustc itself. Over the past two years, we have rewritten the back end of rustc to use an incremental and demand-driven infrastructure. To get the IDE experience we truly want, we need to see that work through for the front end of the compiler as well. However, this part of rustc is one of its oldest, and there are significant design questions involved in how best to do that.

> This is where the RLS 2.0 effort comes in. The plan is to build a prototype of the new front-end, thus enabling a truly first-class IDE experience. Wherever possible, we aim to share code between this front-end and rustc by extracting libraries, such as Chalk (for traits), Polonius (for the borrow checker), and a new library focusing on name resolution. Eventually, we will merge this new front-end with the remaining bits of back-end from rustc.

[1] https://github.com/rust-lang/rfcs/blob/master/text/2657-road...

Getting something like Arduino IDE is for C(++) for microcontrollers out there would be a great step forwards growing the community of Rust programmers.

Also phones and other consumer electronics not strictly IoT, they too could benefit from more secure bootloaders, drivers and OS in general for example.