
Go on Very Small Hardware - onebot
https://ziutek.github.io/2018/03/30/go_on_very_small_hardware.html
======
twic
How similar is Emgo to 'genuine' Go? The syntax looks the same. Perhaps this
is a silly question, but is it garbage-collected?

~~~
shakna
The differences can be found here [0]. The current allocator seems to be a
'allocate once & never free' approach.

[0]
[https://github.com/ziutek/emgo/blob/master/doc/spec.md](https://github.com/ziutek/emgo/blob/master/doc/spec.md)

------
ex3ndr
TBH this is not that small hardware. There are boards with this chip that can
run JS (with interpreter running right on chip)

~~~
Chipndip
Yes, there is smaller hardware - however this is indeed small hardware.
Especially in the context of running go.

This mcu has 4kb, which is not a lot of ram.

8bit controllers are sometimes 16kb - 32kb

------
vanderZwan
Time to plug one of my favourite (semi-academic) programming languages
targeting the embedded space: Céu[0].

It uses a Structured Synchronous Reactive Programming paradigm. Synchronously
concurrency means that it is single-core, and not parallel. More accurately,
it _awaits events_ in parallel (hence "synchronous reactive programming"),
using "trails" instead of threads.

An example from the documentation[1] below:

> _The example in Céu that follows blinks a LED every second and terminates on
> a button press:_
    
    
        input  none   BUTTON;
        output on/off LED;
        par/or do
            await BUTTON;
        with
            loop do
                await 1s;
                emit LED(on);
                await 1s;
                emit LED(off);
            end
        end
    
    

_par /or do ... with ... end_ is an example of two parallel trails, each of
which much have one or more await statements, meaning the block on these
events. The _or_ in _par /or_ means that if either trail finishes, the whole
section ends. In this case, the second trail has an infinite loop (which isn't
a problem due to the await statements yielding control to the scheduler), so
the program only ends if the first trail ends after a button press.

A more elaborate example by fellow Céu enthusiast Johnicholas can be found
here[2][3].

[0] [http://ceu-lang.org/](http://ceu-lang.org/)

[1]
[http://fsantanna.github.io/ceu/out/manual/v0.30/](http://fsantanna.github.io/ceu/out/manual/v0.30/)

[2]
[http://johnicholas.github.io/2018/03/24/Hello_Ceu.html](http://johnicholas.github.io/2018/03/24/Hello_Ceu.html)

[3]
[https://github.com/Johnicholas/learn_ceu_030](https://github.com/Johnicholas/learn_ceu_030)

------
agumonkey
Very very nice article. Nice to see you can use something else than arduino.

------
nurettin
>> arm-none-eabi-size

I wish I knew about this when dealing with MIB520 and MicaZ

------
pjmlp
Very interesting.

