Lunatic brings Erlang's principles to WebAssembly

https://serokell.io/blog/lunatic-with-bernard-kolobara

by aroccoli • 4 years ago

143 39 4 years ago

Rich_Morin• 4 years ago

This seems like a very cool idea. The concurrency model in Erlang/Elixir/... eliminates the issues of shared mutable state and the supervision trees catch unexpected data-related problems, etc.

FWIW, the Elixir/Phoenix community seems to have settled on LiveView, which performs most of the processing at the server, assisted by some small JS routines which handle updates, etc.

tomtheelder• 4 years ago

I think the Elixir/Phoenix community is very excited about LiveView, but I wouldn't say settled. I'd guess only a very small fraction of serious Phoenix apps use it, and most new ones are probably still going to go with some sort of SPA, at least for the time being.

a_bored_husky• 4 years ago

I think its a bit more than a small fraction

https://twitter.com/elixirphoenix/status/1504133097075453953

ch4s3• 4 years ago

I happen to know of a big application that handles a surprisingly large sum of money every day that uses it extensively.

anonymousDan• 4 years ago

Do you know of any projects that seek to run elixir on web assembly in the browser in such a way that it can interact with a standard elixir beam backend?

buescher• 4 years ago

I interpolated an "a" in that headline on first reading.

RcouF1uZ4gsC2• 4 years ago

In Erlang, it feels so elegant – you write your code in a linear way, no coloring of functions, no async/await, and it still works in a high performant, I would say, scheduled way with [inaudible]. My idea was “how can I have this experience in Rust?”.

I think long term, we will view async, like we view the near/far/huge pointers - something that was required in the past for performance but is now obsolete.

With Java’s project Loom, kernel improvements in efficiency of threading, and projects like this, for the vast majority of programmers, using async for concurrency will not be worth it.

laerus• 4 years ago

Algebraic effects can also potentially abstract all this away and make the runtime pluggable.

beanjuiceII2• 4 years ago

has haskell made all this pluggable?

Matthias2474• 4 years ago

I tend to agree. While asnyc/await (and callbacks and promises before) solves an efficiency problem via compiler magic and language extensions, it's not obvious whether it's necessarily the best solution to the problem. The approach that Lunatic seems to take is building another runtime in userspace which takes care of scheduling while allowing methods to continue to look synchronous. A stackful coroutine framework would probably have allowed for the same without requiring WASM, so I'm kind of wondering whether that was considered too.

But ideally we would just use kernel threads, and maybe look into fixing performance for the use-cases where they don't work that well at the moment (which are not a lot actually!). It's so much simpler to understand for most programmers, tools (like debuggers, profilers, etc) just work, and suffers much less from interoperability issues.

astrange2• 4 years ago

I don't think you should add something complicated like async/await purely for efficiency reasons, but it's good for expressivity too. Coroutines are good; I think you'd end up inventing coroutines and CPS (aka calling a callback at the end of your function instead of returning) just because they're useful, but once you have them, they're unsafe and unstructured i.e. you can forget to call them when you meant to.

Async/await does more than just concurrency; it explodes your function into a rather complicated state machine, but at the same time gives you structured coroutine control flow that prevents some kinds of bugs.

That's why Swift added it before concurrency:

https://github.com/apple/swift-evolution/blob/main/proposals...

Some languages have async/await sugar built around futures instead; this is a mistake and it's less efficient too.

sushisource• 4 years ago

A stackful coroutine framework would probably have allowed for the same without requiring WASM

Interestingly Rust actually had this built in originally, but it was taken out of the language since it could be added back in as a library, and the devs thought it was important that Rust did not hide any costs from the user.

Which I can certainly buy. Especially once you consider use cases like embedded development. That said, it'd also suuuuure be nice to be able to opt-in to something like that and avoid the async headache.

sealeck• 4 years ago

Async/await doesn't increase efficiency, it increases saturation.

ekidd• 4 years ago

While asnyc/await (and callbacks and promises before) solves an efficiency problem via compiler magic and language extensions, it's not obvious whether it's necessarily the best solution to the problem.

The nice thing about Rust is that if kernel threads solve your problem, you can just use kernel threads. Some common reasons for using async, however, include:

1. Handling a larger number of connections than the kernel can support using threads.

2. Writing co-routines that operate over streams. This is sort of the in-process version of Unix CLI tools communicating by pipelines. For various reasons, it often seems to be much better handled in async frameworks.

3. Using networking libraries that happen to be async. This is actually fairly common in Rust, and it's arguable not a good reason to use async. On the other hand, Rust has tools for wrapping async code in a sync API, and several of the most popular async libraries do this.

Rust, however, does force you to choose between kernel threads and async coroutines. Rust does not support transparent green threads. This was an explicit design decision, largely driven by two goals:

- Rust lives extremely "close to the machine".

- Rust prefers to make the costs of operations explicitly visible.

Both of these concerns pushed heavily towards removing Rust's original green thread runtime support. However, these two concerns are very specific to languages like Rust that focus on making expensive things visible. Other languages which are more forgiving of runtime overhead would probably be better served by supporting transparent green threads.

jayd16• 4 years ago

Loom looks cool but this comes up a lot but I think async/await covers cases Loom doesn't. When dealing with a situations where you do need to share a single OS thread (GPU commands) or want to use cooperative multitasking (very common in UI) you still probably want something like async/await.

Maybe that just means you pass data between executors in those contexts but I think that will end up looking like async/await anyway.

dang• 4 years ago

Lunatic is an Erlang-inspired runtime for WebAssembly - https://news.ycombinator.com/item?id=28008737 - July 2021 (40 comments)

Lunatic – An Erlang-Inspired Runtime for WebAssembly - https://news.ycombinator.com/item?id=26403879 - March 2021 (2 comments)

Launch HN: Lunatic (YC W21) – An Erlang Inspired WebAssembly Platform - https://news.ycombinator.com/item?id=26367029 - March 2021 (39 comments)

Show HN: Lunatic – Actor System for Rust/WebAssembly - https://news.ycombinator.com/item?id=25160474 - Nov 2020 (47 comments)

the_duke2• 4 years ago

One under-appreciated aspect of async is that it gives you a nice API for composing operations.

Yes, async can be harder to introspect, especially with a debugger, and it introduces function colouring.

But in return it gives you a clear type-system level indication that computations are not pure and don't resolve immediately.

You also get simple tools to combine, map/modify, join and potentially cancel individual asynchronous tasks. You can in theory get a similar API with threads and/or channels, but I've never seen anything that was anywhere as convenient as async.

moonchrome2• 4 years ago

But in return it gives you a clear type-system level indication that computations are not pure and don't resolve immediately.

Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch.

You can in theory get a similar API with threads and/or channels, but I've never seen anything that was anywhere as convenient as async.

I mean you can use the exact same interfaces in .NET and threat tasks as Threads with a custom scheduler implementation (that fires up a thread for each Task you start). And Tasks in .NET implement blocking operations as well as async ones.

piaste• 4 years ago

Is that actually useful ? You can have "BlockingLongCall()" without async and it could block your thread from progressing for minutes - or you could have "await FunctionThatResumesImmediatelyOnTheCaller()" and it doesn't even context switch.

Very much so. Async is - I would guess 95% of the time - a proxy for IO operations.

Error handling is different: a pure function can and should be bug-free, while an IO function can always crash due to external factors. Performance tuning is different: a slow pure function needs optimization, parallelization, and worst case a faster CPU, while a slow async function usually needs you to dive into the plumbing part of your code to see if you're using an API wrong or something like that.

alexklarjr• 4 years ago

My first thought: Oh no, some Erlang lunatic trying to make webassembly even more bad. After reading about newly invented bicycle: What a relief, WebAssembly itself remain untouched by esoteric languages lunatics.

kzemek• 4 years ago

I don’t think calling Erlang esoteric is fair. Niche, sure, but it powers multiple big services and well known enterprises

2wrist• 4 years ago

Nothing clever to say but I love the title.. :-)

MeteorMarc• 4 years ago

Is the title irony or just plain ambiguous?

Lunatic brings Erlang's principles to WebAssembly

Related Stories