I think it is Firefly's approach (https://github.com/GetFirefly/firefly). They put a lot of work into it, but never made it fully functional, and it's not maintained anymore. So I agree that you get smaller binaries…
Compiled to WASM it's ~700K, gzipped only 190K. But there's also BEAM code - the whole standard library is ~3M gzipped. We plan to do tree shaking to only include the used parts of the stdlib - then it should get way…
Tasks seem not to work indeed, but spawning processes works. Try Enum.map(1..10, fn _i -> spawn(fn -> IO.puts("new process") end) end) Also, there are two scenarios: compiling code in the browser and running it, and…
Concerning NIFs, it is entirely possible to write Membrane elements using NIFs in Rust ;) The reason why current ones are written in pure C is that they mostly consist of calls to existing libraries, also in C. We've…
I think it is Firefly's approach (https://github.com/GetFirefly/firefly). They put a lot of work into it, but never made it fully functional, and it's not maintained anymore. So I agree that you get smaller binaries…
Compiled to WASM it's ~700K, gzipped only 190K. But there's also BEAM code - the whole standard library is ~3M gzipped. We plan to do tree shaking to only include the used parts of the stdlib - then it should get way…
Tasks seem not to work indeed, but spawning processes works. Try Enum.map(1..10, fn _i -> spawn(fn -> IO.puts("new process") end) end) Also, there are two scenarios: compiling code in the browser and running it, and…
Concerning NIFs, it is entirely possible to write Membrane elements using NIFs in Rust ;) The reason why current ones are written in pure C is that they mostly consist of calls to existing libraries, also in C. We've…