Hacker News Reader

In general thinking about concurrent code in terms of threads is easier than thinking in terms of async code(it's a lower level abstraction).

> Can you explain this? How is tokio's task different then elixir processes?

Tokio's tasks and go's goroutines and kotlin's coroutines are cooperatively scheduled, i.e a infinite loop can block other tasks from running.

Erlang and lunatic have pre-emptive schedulers(similar to a OS scheduler) that schedule processes fairly by giving time slices to threads.

I'm not familiar with erlang/elixir so I assumed that processes were similar to goroutines:

> In other languages they are also known as green threads and goroutines, but I will call them processes to stay close to Elixir's naming convention.

they're similar, but the developer ergonomics around processes are way better. It's difficult to mess up, coding in the BEAM feels like bowling with those rubber bumpers in the gutter lanes, especially around very difficult concepts like concurrency and failure domains.

Go makes it easy to mess up because the abstractions are superficially simple, but it's a pretty thin layer that you punch through.

The BEAM scheduler is not quite preemptive as I understand it, but in practice it gets close because instead of yield points being defined manually with “await” they are inserted automatically when you return from a function or call a function or do some number of other fundamental operations, and the pure functional nature of the language means that functions are short and consist almost solely of other function calls.

That is how haskell's scheduler works, but I was not aware that it was the same with BEAM. Makes sense.

https://blog.stenmans.org/theBeamBook/#_reductions

A favorite HN comment that discusses this: https://news.ycombinator.com/item?id=13503951

Go read it all but here's a relevant quote:

""" So how does Erlang ensure that processes don't hog a core forever, given that you could theoretically just write a loop that spins forever? Well, in Erlang, you can't write a loop. Instead of loops, you have tail-calls with explicit accumulators, ala Lisp. Not because they make Erlang a better language to write in. Not at all. Instead, because they allow for the operational/architectural decision of reduction-scheduling. """

That is a fantastic comment. I also recommend the BEAM book to those who want to go deeper: https://blog.stenmans.org/theBeamBook/

I haven’t finished it yet but the chapters on scheduling are great.

There's also BEAM Wisdoms: http://beam-wisdoms.clau.se/en/latest/

lol, so BEAM is for schduling like Rust is for memory allocation?

> What part of async Rust is more complicated than synchronous Rust?

The Rust part, of course :) Seriously though, the compiler error messages alone make it a major pain - although I can't figure out if it's an issue of maturity (language and ecosystem), a fundamental tradeoff with Rust's borrow checker, or me just getting way ahead of myself.

I can rarely go a few days of async programming in Rust before running into some esoteric type or borrow checker issue that takes hours to solve because I borrowed some non Send/Sync value across an await point and the compiler decides to dump a hot mess in my lap with multi-page long type signatures (R2D2/Diesel, looking at you).

Those subpar diagnostics are a bug. The underlying reasons are that

- The async/await feature is an MVP

- async/await desugars to code you can write yourself that leverages a bunch of relatively advanced features, namely trait bounds and associated types

- It also leverages a nightly only feature (generators)

- Async programming is inherently harder :)

- We've had less time to see how people misuse the features to see where they land in order to clean up those cases and make the errors as user friendly as they can be

Put all of those together and the experience of writing async code in Rust is similar to the experience of writing regular Rust code maybe two or three years ago. When you encounter things like this, please file a ticket at https://github.com/rust-lang/rust/issues so that we can fix them.

> Working with async Rust is very simple if you are not writing futures yourself.

> Tokio and async-std provide api's that mirror std except for the fact that you have to add `.await` to the end of the operation and add the `async` keyword to your function.

There are absolute pain in the ass problems with `async` currently, in large part due to async closures not being a thing, which means it's very hard to create anything other than an `FnOnce` unless you desugar the future entirely.

Async `Fn*` traits are possible on nightly with the `unboxed_closures` and `async_closure` features.

Yes, by "not being a thing" I meant "not being stable", I thought I'd edited before posting but apparently I only thought of doing so, sorry 'bout that.

I don't consider things enabled by nightly features to be "possible" today, only "potentially possible at some time in the future". The days of using nightly because of a single needed feature in a popular crate are (in my eyes) gone.

And what do you do with functions from external crates that take callback functions but are not async themselves?

You are now limited to non-async functions and if the operation of the crate depends on the return values of those functions, you will need some extreme measures to make it work.

Erlang processes are not green threads.

Green threads can share memory while Erlang processes cannot, they are strictly forbidden to do it.

Also Erlang scheduler is highly optimized to work as a soft real-time platform, so they never run for infinite amount of time, they never block and never (at least that's the goal) bring down the entire application, the worst thing that can happen is that everything slows down but it's still functional and responsive.

I don't know about Tokio.

> Erlang processes are not green threads. Green threads can share memory while Erlang processes cannot, they are strictly forbidden to do it.

So message passing is the only way to communicate between proccesses? I guess that makes sense with elixir being a fp language. This was not clear in the article:

> Lunatic takes the same approach as Go, Erlang and the earlier implementation of Rust based on green threads.

> So message passing is the only way to communicate between proccesses?

There are escape hatches. Obviously, you can do something really heavy like open a network port or open a file descriptor, but it also provides you with use ets, which is basically "really fast redis for intra-vm stuff" and you can transact over shared memory if you drop down to FFI.

Basically only message passing. As another poited out, you can use FFI calls and Erlang Term Storage, possibly some other means to communicate, but the central feature is that each process has an ID, and then you send() a message to it.

each process also has a receive() block where you essentially listen to everything that ends up in your mailbox and pattern match on it to take action.