
Writing a second video game for the Micro:bit in Rust - stestagg
https://medium.com/@stestagg/writing-the-second-video-game-for-the-micro-bit-in-rust-3cd8b5ab22d3
======
bluejekyll
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.

~~~
wyldfire
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.

------
throwaway7645
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.

~~~
ghrifter
> transpiles

can we get rid of this web dev made up word already?

It should be "compiles".

~~~
throwaway7645
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.

~~~
xyzzyz
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.

~~~
winebot
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")

------
wyldfire
Was that "always look on the bright side of life" I heard there?

~~~
stestagg
May have been :). Bitflyer 1 was written in python, so I tried to keep the
monty python references in

------
monk_e_boy
How much are those add on boards?

~~~
stestagg
I don't think they are actually for general purchase(?)

They're being developed mainly for education and learning purposes.

The site is here: [http://www.nevilhunt.com/zbit-
connect/](http://www.nevilhunt.com/zbit-connect/) but please be aware that
this is quite a small operation, so you may not get any success

------
mmjaa
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 ..

~~~
stestagg
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.

~~~
mmjaa
>an older, less expressive, version of python.

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.

Well, its all quite tweakable:

[http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html](http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html)

EDIT: Mike Pall himself has weighed in on this subject, and I thought maybe
you might to hear it straight from the horses mouth:

[http://lua-users.org/lists/lua-l/2005-07/msg00221.html](http://lua-
users.org/lists/lua-l/2005-07/msg00221.html)

.. though, with LuaJIT and eLua around now, things have changed a fair bit
since 2005.

~~~
stestagg
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. :)

