https://github.com/tinygo-org/tinygo/

No garbage collector yet, but it's on the ToDo list and probably not too far off. :)

[1] http://www.eluaproject.net/

[2] https://micropython.org/

Such code would not be able to do I/O directly, but must receive it from outside the sandbox. It could be a pure function implementing a state machine on form `state, outputs = next(state, inputs)`, where state,inputs and outputs are plain data. This structure is amendable to generating testcases, be it via property testing or fuzzing. Or regression tests by capturing a stream of state transitions in serialized form.

There are languages which makes this possible, like Haskell, or maybe even Rust or Ada. However in the embedded world, C is what everyone knows and uses, so there would be a benefit to staying within that ecosystem.

I work in embedded development and the amount of pure logic is really small in our software but I guess that varies with the niche you're in.

The traditional way to simplify QA is to use a Hardware Abstraction Layer in the code, which hardware side-effects happen through. So you have a classic layer cake like:

    | App Logic (imperative, stateful)         |
    | Hardware Abstraction Layer (interface)   |
    | Input/Output (implementations)           |

In the proposed model, the HAL functionality is split into two distinct parts: input and output drivers. And the application logic does not call the HAL, but gets called with Input and produces a description of Output. So the layer cake kinda tips sideways:

    HW input driver > Input (data) >  App Logic (pure) > Output (data) > HW output driver
                                   |                   |
                                   <      State        <

    input generator -> App Logic -> output capture

Those familiar with dataflow programming might find this very familiar. Frontend people might see parallels to unidirectional flow of data in reactive UI frameworks like React. Simulation minded people might see that this structure is very amendable to Discrete-Event Simulation.

I have used this model to good effect across many (relatively simple) embedded/IoT systems over the last few years. One thing I really like, is that it makes temporal logic very easy. Because in this model the current time (be it ticks or wall-time) is just a type of input. So it is easy to stimulate, visualize and make assertions across whole timelines of behavior, and one can see many such timelines at the same time. Similar to what Brett Victor showed with Mario in Inventing on Principle.

Have been meaning to write more about this for a long time, so apologies for the mini blogpost :) Some very related writing in http://www.jonnor.com/2017/03/host-based-simulation-for-embe...

PS: the comment by pault is to the point, and right on the money.

I would like to read a blog post about what you're doing. It would also be great to connect it to the other software communities doing similar things with different names.

I think this encountered these ideas in the Java world around 2005, with their strong focus on testing. It's basically "dependency injection" or dependency inversion.

I just did some Googling and found this good overview:

https://gist.github.com/kbilsted/abdc017858cad68c3e7926b0364...

It's very much an idea in the "enterprise" software world. I've never been in that world but it does seem like they are grappling with complex problems and systems, and this architecture has proven itsef in that domain. It's not surprising to me that it's also useful in the embedded domain.

I would say it's just "modularity". If your dependencies are hard-coded, then you have no modularity in your software at all. The whole thing is one big ball of mud which you can either take or leave. "Functions" aren't really modular if they have nontrivial hard-coded dependencies! (i.e. particularly ones that do I/O or depend on state).

Other names:

- capability based security / Object capabilities (WASM is influenced by these ideas, which originated from Eros OS as far as I know. The E language was an influential object capability language.) The idea of "ambient authority" is useful.

- https://news.ycombinator.com/item?id=14523728 -- a thread where Go programmers are rediscovering dependency injection. You can "invert" state or I/O. Those are independent decisions, but the same concept. In my larger programs, I tend to abstract both of them.

- In Haskell, you use State and IO monads. They are parameters, not things you go "looking for".

- Good overview of enterprise world: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a... (Clean architecture, ports and adapters, onion architecture, hexagonal architecture, functional core / imperative shell, etc.)

I think Java eventually went overboard with "DI frameworks", which I never used. I just wire up the dependencies manually in main() and it works fine.

-----

Also, I bought a somewhat obscure many years about dataflow programming and hardware, which I think it somewhat related:

https://www.amazon.com/Programming-SIMPL-Way-John-Collins/dp...

At its most fundamental, SIMPL is a set of library functions which allow the passing of encapsulated messages between cooperating processes. These processes may be local to one host computer or spread over a network.

WASM was made with running on regular desktop CPUs in mind. Wasm is not a truly a state machine, nor stack machine, but a horrible hybrid in between them thanks to design by committee.

Changeable locals, accessible undefineds, use of stack pointer protection technique that kills both pipelining and speculative execution. Yes, that's combined downsides of both stack and register VMs.

There were MCU that were naively running Java long time ago, but all failed on the market. The idea proved non feasible

To be clear, this is also interpreted, so it doesn't have an advantage there.

Not sure they failed for technical reasons, embedded CPUs just got fast enough and typical memory big enough to run a JIT.

Really no value there. The positive connotation of "web native" label is not so positive in the world of dour and severe people which "hardcore embedded developers" are.