Why can't we get Rust for the ESP8266? :( I really dislike C, I'd love a higher-level language. As great as MicroPython is, the interpreter needs too much RAM, and I think Rust would be a great alternative.
What's wrong with Lua? It has first class support thanks to NodeMCU, you can customise your firmware builds to be lean on resources using a dead simple online tool, and it even lets you run code on the ESP8266 in an interactive REPL environment.
Lua is strictly worse than MicroPython, I find. Memory usage is worse, and managing programs on it is bad too, although I haven't used it as much as MicroPython.
As for Rust, why do we think that should use significantly less memory than MicroPython or Lua? I've seen some threads with people doing measurements on simple programs and finding Rust up to 10x heavier on RAM than C.
You would need a basic standard library built with the binary when building for xtensa (esp) aswell. So yes, the size of the core parts of the stdlib between c and rust definitely do play a role.
My problem with Lua and MicroPython is that your actual code takes up memory, ie even comments. Micropython can now compile to bytecode and load that, though, so it's better. I've had problems with Lua trying to load one or two hundred lines, though.
As a side note, there are quite a few options to do safe micro controller system programming for those that prefer AOT compiled languages without C like unsafety.
I think Forth is much more suitable here. You can implement a lot of features in 512K. You can extend the code (and language!) at runtime, you can debug remotely, and do other nice things.
These Rust trolls (at least I hope, for your sake, that you are trolling here and not serious) are getting annoying.
One would wonder how we managed to cope before Rust.
Also, you should ask these guys [1] [2] how they know they're using memory safely. Has Rust ever been used to fly aircraft and fricking space shuttles? I didn't think so.
Rust has Tier 2 support[0] for ARMv6 to ARMv8 and Tier 3 support[1], so there are experimental limited[2] backends for the various Cortex in Tier 3.
However the ESP8266 is built around Tensilica's Xtensa, not ARM's Cortex. There currently is no support whatsoever for Xtensa in LLVM (let alone in Rust).
Current microcontroller work is on MSP430[3] with work being planned for Amtel AVR[4] since the AVR branch was merged into LLVM in November 2016. Xtensa is quite literally nowhere[5].
[0] guaranteed to build & binaries provided but tests are not automatically run
[1] supported in the codebase but no guarantees that it even builds
>However the ESP8266 is built around Tensilica's Xtensa, not ARM's Cortex.
DOH!
I have to say, though, that having the AVR code generator merged is very cool. At one time I was a big user of avr-gcc and remember when the AVR LLVM effort was just getting started. I haven't been following it, though.
One of the annoyances with gcc is that the optimizer kept wanting to use code motion to relocate the interrupt disable instruction to the beginning of the function it was found in. The only way to keep the optimizer from doing that would have been to make the instruction depend on all of RAM, which would effectively disable optimization for any function that disabled interrupts. So coding critical sections required a bit of jiggery-pokery to keep the optimizer from breaking your code. I hope the LLVM back-end found a way around that.