Extending the scope of Gleam nearer the metal

[CrowdHailer]

This is a very speculative issue and not something I am sure is even possible.

Is it possible to have the ergonomics of Gleam when writing embedded code?

The Beam can already be run on fairly resource constrained systems, nerves is proof of this. However these systems still have a lot of layers between the program and the machine, OTP/processes/Beam etc. I consider a higher

*Removing OTP is one interesting idea to remove complexity, but is not the thrust of this issue, see https://github.com/midas-framework/erlang_library_runtime for more details)

How far can the value of a gleam type system move down the abstraction chain.

OTP -> beam -> runtimes with limited concurrency(ruby/python/JS) -> Nim (maybe it belongs here) -> Rust -> Make your own adventure (i.e. C).

Move/Copy/Linear types

One way of tracking variables that refer to non duplicable items, like ports/sockets etc. But would be an addition to Gleam and probably a compromise in it's simplicity when tackling other problems.

A counter argument is even higher level programs have values that should only be used once. i.e. a conn in Plug. (A counter counter argument is that this is not a good way to design API's)

Flux/State container for hardware

fn loop(machine, interupt) {
  let Machine(gpio_1: is_on, ..) = machine
  let is_on = !is_on 
  Machine(..machine, gpio_1: is_on)
}

This solves the problem of needing linear types to make sure an old reference to a pin is not used after the pin is modified as the pin modification only happens after the function has returned. This is the same basic idea as Flux + virtual Dom where the Real Dom (in our case Real Pin) is only updated after the function returns.

• Peripherals as State Machines

Not solving anything in Gleam Land.

Maybe it is impossible to have a one language for all, maybe the best solution is to have Rust or something else that is called from Gleam programs when needing to interact with hardware etc.
I have a reticence with this approach because I think it is quite possible that in a project that starts with Rust you might stick with rust and not realise the time to move up an abstraction. For this approach to work I think there needs to be a template project with Both rust and gleam code that can be set up.

LibraryOS exokernels

Not necessarily related but I think interesting because I suspect that this would be the way to rely on Rust components in a Gleam environment.

• short intro to exokernel
• https://en.m.wikipedia.org/wiki/Singularity_(operating_system)
• libOS look at gcloud work 14 min

Go unikernels are more mature than most and include a runtime with concurrency

Note Unikernel and manual memory management is not the same problem. manual memory can be compiled to binary in large OS. Unikernel/microcontrollers, can run GC envs with access to pins?

Prior Art

A fairly small set of languages are looking at bringing higher level abstractions to program while still allowing manual memory management.

Nim

• https://forum.nim-lang.org/t/6236
• multithreading
• memory management

Zig

• Nice ideas on never (really never) having errors
• https://ziglang.org/learn/why_zig_rust_d_cpp/

V

Looks complicated, has built in ORM!

D

Odin

https://odin-lang.org/

Not simple enough.

• https://dlang.org/comparison.html

Roc

Interesting ideas to separate Platform and Application.

Goals to build in official editor, and long time scales

Hume

http://www.macs.hw.ac.uk/~greg/hume/

---

QEMU internals for testing

[lpil]

I would like to start by looking at micro Python. It is a version of Python that is capable of running on micro processors that doesn’t burden the user with any additional memory management work. It’s is obviously not as fast as C or Rust but for this kind of work the ergonomics are unparalleled.

Another thing to consider is that structural sharing data structures may not be possible in such an environment where everything (I presume) is on the stack. Research would need to be done into the limitations here, and how Gleam would work in a mutable world. I’m not entirely convinced that Gleam would be a very good language with mutable data structures and for loops.

Also prior art should probably include Rust as it is higher level than Zig or Nim yet has less runtime and so can be more widely used in embedded programming.