mathek · HackerTrans

السنة الماضيةdiscuss

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 this way, but I believe we can get to acceptable sizes too, without creating and maintaining a custom compiler.

mathek

السنة الماضيةdiscuss

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 smaller for most use cases.

mathek

السنة الماضيةdiscuss

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 running precompiled code in the browser. In the latter case more things work, for example the 'game of life' example uses GenServers, Supervisors and Registry:

https://popcorn.swmansion.com/game_of_life/

https://github.com/software-mansion/popcorn/tree/main/exampl...

But yes, it's still unstable. Improving the stability is our main focus right now.

mathek

قبل 8 سنواتdiscuss

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 experimented with using Rust, but we ended up with most part of our code being unsafe calls to library functions, providing more boilerplate than profits. If we are to create a considerable big native part of Membrane, we will definitely consider using Rust.

comments