3 ms·

Coming from Go which introduced me to the concept of lightweight threads, I really miss goroutines and Go's concurrency model with channels/select/cancellation/

Coming from Go which introduced me to the concept of lightweight threads, I really miss goroutines and Go's concurrency model with channels/select/cancellation/scheduling. However, targeting WASM seems like a pretty huge compromise to doing this natively in Rust. Conversely, it looks like what you're trying to do wouldn't currently be possible without the WASM/WASI stack. Curious what your thoughts are about not implementing it as a Rust runtime target? Did you investigate this and why did you rule it out if so?

bkolobara 6y ago
I don't see it as a compromise. Using Wasm allows for some really nice properties, like compiling once and running on any operating system and CPU architecture. Lunatic JIT compiles this code either way to machine code so the performance hit should not be too big. When you say "implementing it as a Rust runtime target", I assume you mean targeting x86/64. In this case it would be impossible to provide fault tolerance. The sandboxing capability of Wasm is necessary to separate one processes memory from another.
nahuel0x 6y ago
Note, the Go model falls short against the Erlang/Lunatic one. You can't externally kill a goroutine at arbitrary points (you need to cancel them with a cancel chan / context with manual checking). You can't prioritize a goroutine over others. You can't serialize a goroutine state and send it over the network. You can't fork a goroutine. You can't sandbox a goroutine. Etc. Using WASM is a tradeoff, but WASM is very fast, surely faster than BEAM process.
- didibus 6y ago
  > You can't externally kill a goroutine at arbitrary points Why not? Isn't that just an artifact of Go's implementation, or is there fundamentally something in CSP that prevents this?
  - skybrian 6y ago
    It's essentially cultural. A fundamental assumption of the Go language, implementation, libraries, and community is that goroutines share memory. You don't write concurrent Go code assuming that a Goroutine could arbitrarily disappear, so breaking this assumption will break things. Lunatic is not like that: > Each Lunatic process gets their own heap, stack and syscalls. Similarly, Rust code that uses threads and/or async isn't going to work in Lunatic (or at least won't get the advantages of its concurrency model) without being rewritten using Lunatic's concurrency primitives. The concurrency model is more like JavaScript workers or Dart isolates, though hopefully lighter weight. I'm guessing that the Rust language might work well because move semantics assumes that values that aren't pinned can be moved, and that's a better fit for transmitting messages between processes. But there will probably be a lot of crates that you can't use with Lunatic. If it became popular, it would be forking the community at a pretty low level. You'd have some crates that only work with Lunatic and others that use async or threads.
latch 6y ago
Go's concurrency model seems like a compromise: https://play.golang.org/p/DAoobz43yud https://play.golang.org/p/DAoobz43yud OR https://play.golang.org/p/m0VntGBORBw https://play.golang.org/p/m0VntGBORBw Also, I can't think of what scheduling capabilities Go's concurrency has?
- nkozyra 6y ago
  I'm not sure I understand your second example qualm. That's logical described-on-the-box behavior.
  - latch 6y ago
    Because the behavior is merely described, not enforced. It's relying on everyone to obey the two design rules that: 1) only the writing side should close the channel and 2) only one side should write. In this sense, it's as safe as mutexes: everything works as long as everyone (including any 3rd party library) does exactly what they're supposed to. When compared to what modern and robust concurrent programming looks like (e..g Erlang), it seems like a compromise to me
fluffything 6y ago
You can have millions of coroutines in flight in Rust using async/await without issues. This app explicitly wants to use threads, for some reason.

bkolobara 6y ago

I don't see it as a compromise. Using Wasm allows for some really nice properties, like compiling once and running on any operating system and CPU architecture. Lunatic JIT compiles this code either way to machine code so the performance hit should not be too big. When you say "implementing it as a Rust runtime target", I assume you mean targeting x86/64. In this case it would be impossible to provide fault tolerance. The sandboxing capability of Wasm is necessary to separate one processes memory from another.

nahuel0x 6y ago

Note, the Go model falls short against the Erlang/Lunatic one. You can't externally kill a goroutine at arbitrary points (you need to cancel them with a cancel chan / context with manual checking). You can't prioritize a goroutine over others. You can't serialize a goroutine state and send it over the network. You can't fork a goroutine. You can't sandbox a goroutine. Etc. Using WASM is a tradeoff, but WASM is very fast, surely faster than BEAM process.

didibus 6y ago
> You can't externally kill a goroutine at arbitrary points Why not? Isn't that just an artifact of Go's implementation, or is there fundamentally something in CSP that prevents this?
- skybrian 6y ago
  It's essentially cultural. A fundamental assumption of the Go language, implementation, libraries, and community is that goroutines share memory. You don't write concurrent Go code assuming that a Goroutine could arbitrarily disappear, so breaking this assumption will break things. Lunatic is not like that: > Each Lunatic process gets their own heap, stack and syscalls. Similarly, Rust code that uses threads and/or async isn't going to work in Lunatic (or at least won't get the advantages of its concurrency model) without being rewritten using Lunatic's concurrency primitives. The concurrency model is more like JavaScript workers or Dart isolates, though hopefully lighter weight. I'm guessing that the Rust language might work well because move semantics assumes that values that aren't pinned can be moved, and that's a better fit for transmitting messages between processes. But there will probably be a lot of crates that you can't use with Lunatic. If it became popular, it would be forking the community at a pretty low level. You'd have some crates that only work with Lunatic and others that use async or threads.

latch 6y ago

Go's concurrency model seems like a compromise: https://play.golang.org/p/DAoobz43yud https://play.golang.org/p/DAoobz43yud OR https://play.golang.org/p/m0VntGBORBw https://play.golang.org/p/m0VntGBORBw Also, I can't think of what scheduling capabilities Go's concurrency has?

nkozyra 6y ago
I'm not sure I understand your second example qualm. That's logical described-on-the-box behavior.
- latch 6y ago
  Because the behavior is merely described, not enforced. It's relying on everyone to obey the two design rules that: 1) only the writing side should close the channel and 2) only one side should write. In this sense, it's as safe as mutexes: everything works as long as everyone (including any 3rd party library) does exactly what they're supposed to. When compared to what modern and robust concurrent programming looks like (e..g Erlang), it seems like a compromise to me

fluffything 6y ago

You can have millions of coroutines in flight in Rust using async/await without issues. This app explicitly wants to use threads, for some reason.