Not sure the author is posting here, but I'm curious about people's experiences with Rust in these non-stdlib scenarios.
In my Rust I rely so heavily on the stdlib, and other crates, that it's hard for me to imagine working in an environment where I would not have access to that.
It's analogous to when you're using C to write a bootloader or OS or something. Yes, it's restricting, but that's typically the nature of those environments. The cool thing about Rust is that at least you have powerful abstractions you can use.
But the cool thing is that you can conveniently compose other no_std crates into your stuff. No more futzing about with m4 or global namespace collisions or did-they-leverage-some-weird-dependency-that-I-can't-build-here.
Hi! It generally didnt matter too much to me, there were a couple of times where I missed a container that could help, but for such a constrained environment it wasn't too much of a burden.
With the nightly compiler, you can get most of the non-OS dependent parts of the stdlib via the core, alloc, and collections crates. As others have mentioned, a lot of the more basic stdlib functionality is a re-export of core.
Have you given a thought to Nim? I've never used it in the embedded space, but it should work there nicely. It has Pythonic syntax, but it transpiles to C, so it should fit both your criteria. I'm not sure how the GC fits in, but i think you can turn it off if it becomes problematic. I'd love to see the comparison. Rust is powerful, but I'm guessing a good bit more complicated as well.
What's wrong with inventing new words to clarify meaning? The C preprocessor is also "just" a compiler but no one calls it that, for good reason. A disassembler is similarly "just" compiler, but no one calls it that.
And, as sibling commenter noted, "transpilation" is a concept that predates the web itself, let alone "web devs."
I think "compilers for which both the source and target languages are usually written by humans" is a useful category. They face some fairly unique issues, like having to plan around a second optimization pass geared towards human, not machine, output. I'm not sure why it's such a big deal to you the particular word used, since it AFAICT was never used to mean anything else.
It transpiles to C, which then compiles to machine code. I think Transpiling is the right word here. I guess you're right that you can compile to anything, but "transpile" seems more descriptive.
Compiling is literally translating from one language to the other, usually simpler one. There historically has been tons of languages compiling to C (e.g. various Schemes), and there was no need to invent a new word for it.
One of the great things about natural language, is that we can create new words, in order to arrive at more fine grained meaning. I personally can appreciate a difference between a compiler that takes source code in one language and generates source code in another high level language, and a compiler that takes a source file outputs a binary.
Granted, there are a lot of situations where there is no need to make a distinction, but that's not always the case.
An analogy might be the use of the words car and taxi. Cars and Taxis are both vehicles. In fact, a taxi is often a car.
In some situations, I might say "I went there by car" - and that would be sufficient. But if the situation demanded I express the fact that the car that I traveled in was a taxi, I would say "I went there by taxi" (Not "I went there by a car that is owned by a freelance driver who charges by the kilometer")
Agreed, but like a child comment said, this is a lot more popular now, and new words pop up all the time in natural languages. I get your point, but to me it adds clarification in Nim's case as compilation could mean going to JS, C, C++, or we could be talking about the part where that is passed to gcc or the web browser or whatever.
So classical C compilers are also transpilers and we should refer to them in this way, as they do source-to-source conversion from C text code into Assembly text code.
"Transpile" is simply more specific than compiler. You can refer to them in this manner if you wish to be more specific, but compiler is still okay, as transpilers are just a subset. (The C ASX compiler, when converted to .ast, was referred to as a transcompiler.)
While I'm all for learning Rust on new platforms, I'm curious why something like Lua wouldn't be more appropriate for this particular use case. Maybe Rust was chosen just to scratch an itch, but it seems like the author could have given a little thought to using Lua in this environment, too ..
Interestingly, I hadn't even considered Lua for this in any way.
In my (entirely unresearched, and opinionated) mind, Lua is in spirit, an older, less expressive, version of python. I know there's some impressive and interesting jit/compiler projects around lua that make it great, but it doesn't seem to help with the actual problem I was facing, which was low ram.
The nrf51822 has 128kb ROM, and only 16KB ram, so any allocations that happen at run time are comparatively VERY expensive.
bitflyer has about (guestimate) 40kb of static resources, for bitmaps and music. This means those resources had to be static, and loading/managing them in ram is hard. As an example, to buffer the display in memory is 1/16th of your entire ram.
With rust, this meant that I effectively had a 14kb stack, that is almost guaranteed to be non-fragmented, (I haven't got round to measuring the actual stack size, but I think probably no more than a 3/4 Kb actually used on average) and no heap to worry about.
As far as I can tell, Lua uses a heap-based GC model which means unpredictable usage, and fragmentation.
Wow, that's a bit of a pity, yo. I don't think thats at all correct. They're completely different languages and ecosystems. Where Python has a fat history, Lua is mean and light.
>As far as I can tell, Lua uses a heap-based GC model which means unpredictable usage, and fragmentation.
Sorry, that wasn't meant as a slur on the Language, just an expression on my uninformed background-opinion of it, trying to explain why I didn't go for this.
As for the eLua tweaks, things like rotables are quite cool, but ultimately you loose the ability to define them in lua, so, like micropython, it's doable, but just means you sacrifice the non-c nature of it to do so. :)
In my Rust I rely so heavily on the stdlib, and other crates, that it's hard for me to imagine working in an environment where I would not have access to that.