Rust effectively accomplishes this, because mutating a value that's accessible by a different thread requires both interior mutability and a separate Sync trait, meaning that accesses will be properly synchronized. Some types implement this (atomic types, Arc, Mutex, Rwlock) but the default is not to, so the default is that data may only be mutated by a single thread at any given time.

There are languages where everything is an actor, like Erlang. I said what I said because I worked in them professionally for many years. While there is incremental benefit to being 100% actors versus 90% actors, I don't think it's that impressive of an incremental benefit, and is easily overwhelmed by many other factors. That's why I work mostly in Go and borrow actor structures when helpful. That turns out to be every non-trivial program I've written so far... but there's no particular benefit and often non-trivial costs in trying to write the whole program as actors, rather than using actors as useful servers. The simplification of being able to look at something and just know it's an actor I don't find very helpful. It's not hard to document these things, or see them in the structure of the code.

By contrast, 90% pure functional programming is a pretty terrible paradigm. You really need to push that number up to get the benefits. As you approach 100% I think the benefit starts to take off. But, speaking very sloppily since "percent pure functional programming" is kind of difficult to precisely define, 90% is like the worst case scenario. 20%, which is to say mixing it in to other paradigms when useful without commitment and without paying much price and just harvesting the low hanging fruit can be very nice, and 99.9% can be very powerful, but 90% is the worst case, where you're paying most of the price but getting few of the benefits of true commitment. This is what I mean by seeing a lot of benefit in going the full way. I don't see this benefit to actors. They work just fine embedded into large programs and deliver the vast bulk of their benefit without having to structure the entire program around them.

Definitely still worth learning; I consider them a core technique in concurrency programming. When you can easily afford the message marshaling and concurrency expenses, they are one of the easiest ways to get concurrency without complexity. And most of the time, you can afford those costs.

Minor nit: In a language like Erlang, function calls (including tail recursion) are instrumented to implement things like preemption, GC, and statistics updates. But loops (backward branches) can just as easily be instrumented, and various imperative language runtimes do so.

Erlang is somewhat unusual among contemporaries in how it multiplexes actors onto system threads. This has historically been quite difficult to get 100% right because even if you manage to make all system calls non-blocking (e.g. TCP socket I/O), "non-blocking" disk I/O can still stall computation for a relative eon. I'm pretty excited about io_uring because it provides a general solution to this problem.

As far as I know the biggest diffeence between Erlang’s GC and other GC algorithms is that the former only has to work on a small local heap.

This also works to a degree in Java with thread local allocation buffers. Objects get allocated on a thread local basis and only move to a shared heap generation when they lived for long enough, or are being shared to another thread.

Re GC and scheduling: You're not going to like this, but like I said, I worked in this space for many years, and my assessment is that in 2022, these are not relevant. It might be relevant if Erlang was a much faster language, but it's not. It doesn't matter to me that Erlang's GC is hypothetically faster because of its actor model when Go is just straight-up so much faster across the board that it doesn't matter.

Whether a fully compiled language could recover this I don't know, but I doubt there's any room in 2022 to spank a modern GC by more than a few percent as a result of this. By the time you're getting to the scale where this is a problem, everything's a problem anyhow.

Likewise for the "seamless distribution". I don't need it, because the direction everyone has gone is to use other messaging busses like Kafka or the literally dozens of similar products that exist now. I don't need actors to achieve this. The historical accidents of how Erlang achieved this goal are not necessary. This is a classic Erlang mistake, to think that only that one precise space in the design space can achieve these goals, and not noticing just how many other alternatives in this space have straight-up surpassed Erlang in the meantime.

Fault tolerance is another thing that I've been operating on just fine with an 80/20 solution. I actually use my own version of supervisor trees, and while I lack language guarantees of their safety, the truth is they work just fine even so. Language guarantees aren't everything.

It's not that you're wrong in the sense those benefits don't exist, it's just, in 2022, they're not very interesting. It's not 2005 and Erlang is the only practical solution to these problems. It's 2022 and there are an abundance of other solutions, and while they may all have corresponding disadvantages of their own, the probability in 2022 that Erlang is the best choice for any given task really isn't all that good any more. I happily trade away the marginal improvements you mention for 80/20 solutions in Go, while I claim Go's very significantly better performance across the board, for instance. Rust, Node (as much as I otherwise despise it), and many other solutions provide other solutions in the space.

What Erlang gives up to force things into "everything is an actor" aren't things I want to give up anymore. A worthy experiment for the time but I view it in much the same way I view Java's "everything has to be in a class, even pure functions and stuff that ought to be standalone code". Nice try, but there's a reason numerous languages have been introduced since Java/Erlang and don't copy this particular purity. You just don't get the promised win. It's great that we tried it. I wouldn't know we don't get the promised win if nobody had. But now we have, and there isn't some amazing burst of benefit at that last step of purity.

(I keep banging on pure functional programming because it's honestly the only one that comes to mind. In general, you should be suspicious of anyone who claims that particular shape of purity vs. benefits, in practice few things work that way and you should only trust practices that yield marginal benefits as you marginally use more of them, and expect that somewhere before 100% purity the benefits will start toning back down again. Maybe software transactional memory is the other exception that comes to mind; it only works at all with near-total dedication.)