i hope to see fm-1.5 with sd card soon to make it sampler. or is it time for hardware mod?..

Nope, I'm not buying. This is roughly "any executable binary can be decompiled to C" which is kinda true, but we both know it's not how the real world works. Compilation is lossy, parsing to AST is almost lossless.

> the cost of compiling to source

But now you paid this cost a second time. To build textual Erlang source programmatically, you need some kind of AST anyway, as I highly doubt you were using direct text templating. So you had an incomplete copy of Erlang Abstract Format, which is THE Erlang AST, but had to write your own pretty-printing.

If I were to implement code generation targeting BEAM in language X I would start with making some tool(in Erlang) to fetch abstract format definition from erl_parse typespecs and make code generator to X emitting matching definitions and ETF serialization code. It is relatively simple, it is unavoidable anyway, and it lets me avoid bothering with textual Erlang puctuation.

I just don't get it. It's not even fun!

Also I'm currently playing with idea of compiling Core Erlang via OCaml backend, there is a mirror problem - parsing of Core into OCaml terms. And no way I'm implementing proper lexing/parsing of Core, I'm going with ETF right from start.

but talking pejorative, i was surprised. my opinion of gleam was already pretty low, but i did not expect to see post-1.0 compiler emitting text erlang source. maybe it's not that good of idea to implement compiler in language completely foreign to target ecosystem.

they do some releases, they have a somewhat big project of rewriting vm in zig.

File I/O or everything else treated as syscall by Go runtime might turn you program into 10k-os-threads-monster. Scheduler will be creating new OS threads to replace those locked on syscalls until thread limit is reached and whole program crashes. Only way to prevent it is to restrict your syscall layer into fixed-size goroutine pool.

I had an interesting case recently - my app serves some data from tons of files laying in NAS, accessing it by NFS mount and one day NAS hunged completely, every I/O call to it was lasting forever. Even 'ls /mount-point-of-nas' was just doing nothing forever until Ctrl-C. In my case I've applied poweroff-poweron cycle to NAS, and everything went right in minutes, just as NAS booted. And after it I wondered, what if my server was written in Go, instead of Erlang...

And, BTW, you can never be sure, that underlying libraries of your code are safe to use.