Hacker News Reader

Kind of agree. The erlang runtime just gives you a process abstraction that is extremely cheap. So within a process you can do things logically sequentially without dragging the system as a whole down.

This approach would not have been the right choice for rust itself, since rust as a systems programming language can not have a runtime.

But there is a fun project called lunatic that implements a lightweight runtime in rust https://docs.rs/lunatic-runtime/latest/lunatic_runtime/ and then allows you to write lightweight processes for this runtime also in rust https://docs.rs/lunatic/latest/lunatic/

It seems heavily inspired by the actor model and erlang.

> Continuations and the way Erlang handles this have far less mental overhead and help keeping the model and the mental representation of that model in sync. Differences between the two is where bugs will hide.

You still have a lot to think about in Erlang. For example, you need an entire supervisory system to handle the fact that an actor can die. You need to handle the fact that an actor A might send a message to actor B and not get a response, or it'll get a response way later. You need a native way to link actors, a native way to name actors, a tracing system, etc. Actors are not something you can simply slap onto a system and suddenly you've got Erlang superpowers.

TBH tokio tasks give you a very similar abstraction without the problems - you can join a task. That's a huge ergonomic improvement because you can isolate/join state at will without having to use a channel.

> it's an ugly wart on Rust and a distraction to boot.

It's really not that bad. Like, IMO the major reason to have async is for cancellation. I want to be able to have a network request time out. That is way, way easier to handle in async code than threaded code. The best I can do with a sync system is specify timeouts on an underlying resource like a socket, I can't do anything like "this specific request should have this specific timeout" without async.

The supervisory system is an extra, you don't technically need it but it can help make your application bullet proof and I would definitely recommend if you go the Erlang route to use it to your advantage.

Every other language and/or runtime will need something similar anyway, but there is a good chance that it won't be nearly as elegant (as as solid) as the way Erlang does this.

Agreed that actors are not something that you can slap onto an existing system, but you can build systems that use a lot of those lessons effectively without them being written in Erlang.

> It's really not that bad. Like, IMO the major reason to have async is for cancellation. I want to be able to have a network request time out. That is way, way easier to handle in async code than threaded code. The best I can do with a sync system is specify timeouts on an underlying resource like a socket, I can't do anything like "this specific request should have this specific timeout" without async.

That's a great way to end up with orphaned resources though. If you kept it at the process level that simply could never happen, your process would error out, the supervisor would take over and that would be that.

> The supervisory system is an extra, you don't technically need it but it can help make your application bullet proof and I would definitely recommend if you go the Erlang route to use it to your advantage.

An actor system without supervisors is throwing away a lot. How do you handle an actor that crashes? The thing is, again, Actors are very low level - they're a foundational model. You end up having to build protocols and systems on top.

> If you kept it at the process level that simply could never happen, your process would error out, the supervisor would take over and that would be that.

I don't think you're going to get an orphaned resource by timing out and dropping the future, which drops its state.

I am responding to the very last point about dropping a future and the resource usage.

Let's assume a future that implements reading from a network socket. And the file descriptor (fd) was already passed to epoll/select (I am ignoring io_uring).

After dropping the future, the socket is is still being considered by the kernel for reading. Eventually epoll will return, and the IO runtime (like tokio) will notice the stray fd and discard it. And can you even close the fd before it is out of epoll?

So until the fd is back to user land, it appears very similar to leaking resources. Even if only for a short time while the IO loop is completing an iteration.

I'm not sure how an actor would solve that problem. You're describing the way a system call works, which is not relevant to how your userland asynchrony works. In either case you're always "leaking" (I'd say "holding") the resource while you wait for the kernel to give it back to you.

Indeed I was merely describing how it behaves within the context of future + ioloop with tokio. I didn't take a stance on future vs actor.

In Rust my instinct tells me the difference between actor and future is negligible. Because it compiles down to almost the same thing. But I wouldn't bet my life on it.

Note that my understanding of what an actor is might be wrong. I assume an actor is a sort of thread with a main ioloop receiving and sending messages. Which is basically what a tokio ioloop thread is. Atop of which the futures give you an abstractions to compose IO functions more easily.

Yep, that's basically an actor.

You seem to be mostly arguing that all the building blocks are in place and you can assemble your own LEGO.

Which is exactly what I started disliking lately. I want async Rust more opinionated with much more huge red arrows pointing in the right directions for cases A, B and C, and links to docs and even 3rd party crates for cases from D to Z.

Oh, hey again. :)

And yes I work mostly with Elixir for years and Erlang's model is just irreplaceable so far. You're quite right that everything is synchronous but all the Erlang "processes" (green threads, fibers or w/e people want to call them) are preemptively and forcibly switched. And that has basically eliminated 95% of all parallel programming problems.

I would kill for Erlang's concurrency / parallel primitives in Rust, especially if they come with their own DSL (likely via Rust proc macros?) and are much shorter and comprehensible than they are right now. :|

> It essentially gets you all of the complexity of interrupt driven code for very little gain

Yep, sadly. I've written some fairly impressive commercial Rust code but it added gray hairs and left me wondering whether that was the best way to do it.

In a way it really gets me: we have a very good solution and yet everybody is pushing their own novel footguns with gusto. Baffling, really when you think about it. I'm trying to imagine civil engineering with entirely new ways to design bridges every 4 months, different materials that are entirely untested but this time we'll get it right and so on. That's roughly the state of the software world.

Oh don't even get me started on this, I start fuming just by reading your comments because they often align very closely with my thinking (in other threads as well).

I really think we should all pull up our sleeves and e.g. make transpilers from TLA+ to every mainstream language. (Provided we first made sure TLA+'s parallel logic is exhaustive and flawless, of course.)

I too get super ticked off these days. The programmers at large are constantly running in circles and almost nobody seems to care and everyone loves to pretend that this is exactly how things should be... Argh!

It isn't a well received opinion, but this kind of stuff, like in other engineering domains, can only be fixed by liability and regulation.

Most people (and companies), don't care for quality unless ignoring at it comes with a fine.

Liability is the big one. As soon as that kicks in a lot of this absolutely irresponsible stuff will stop.

Regulation would still be playing catch up but being liable, preferably all the way to the people involved including directors, could be done pretty fast and would set us on the path to licensed software engineer in short order.

Indeed, and the "what about the poor FOSS developer" isn't something I buy in.

The small little street bazaar salesperson, the little corner shop, big shopping mall, whatever, all of them are liable and manage to make their business just as well.

Keep an eye on gleam lang if you’re not already. It’s a language with an ML inspired type system (like rust) that compiles to erlang. It is likely too nascent to be used in production (in terms of tooling, ecosystem, stability, etc).

https://gleam.run

I do already keep an eye on it and I like its syntax a lot. Problem is that the current commercial Elixir ecosystem is very strongly gravitating towards web and API development where several libraries reign supreme (Phoenix [web framework] and many of its dependents and derivatives, plus Absinthe [GraphQL] and Ecto [databases]). They also heavily rely on Elixir's macros so Gleam has quite a lot of work to do before it gains any tangible switching-over power.

To be honest... I am more likely to learn Golang more deeply (I know it quite well already but haven't, like, programmed in it in production for a long time, I am mostly using it for my own scripting and personal project needs) or even dive into OCaml now that it has a multithreaded runtime.

I do like how enthusiastically people make new languages but IMO most of them should be absorbed back into the hivemind at one point. This huge fragmentation does not help anything (except maybe teach you a technique or two which is of course very valuable by itself).

I think part of this is the ego component: it's much more fun to make a relatively big contribution to something new than it is to fix a small part of something much larger.

That, plus many programmers are former nerds who just love tinkering with stuff and they invent languages as thought experiments. Which is 100% cool with me but it gets weird when they start to promote them...

And figuring out the gap between "wanting to tinker" and "being a reliable paid professional" is a big struggle that takes a while to figure out -- and maybe takes your entire life in maintaining a good balance between both.