This may actually belong over at Ethereum 2.0 Data Model: Actors and Assets - #6 by fubuloubu, but since I’m responding to things in this thread, I’ll put this here for now. Apologies for the categorization error 
being written in a subset of Erlang (I think?)
RChain have their own abstraction, called the Rho Calculus (an extension of Pi Calc) that is essentially formalism for the actor-style concurrency, and have used it as the basis of RhoLang. The primary implementation is in Scala, and yes, has a very “unique” syntax.
Personally I do think keeping the developer experience close to what they’re used to and not adopting weird programming models that require them to completely change their thinking is something that heavily contributed to ethereum’s current success and it would be very valuable to keep it.
I agree, broadly! Ethereum should be as approachable as possible. There is a balance, though: people are spending a lot of time learning EVM internals and getting bitten by expensive bugs (Turing Tarpit, &c). We’re already seeing the rise of Ethereum-specialist programmers in commercial contexts.
Not necessarily arguing for switching, but just my two cents worth: Erlang’s Prolog-ish syntax looks unfamiliar, but there are others like Scala (widely-used) and Elixir (praised for syntax and ease-of-learning). The actor model is closely related to OO — in fact, essentially the original OO paper is really the actor model. These languages don’t need to seem unfamiliar (see Elixir), and inter-actor calls between actors can looks as simple as the .call that we have today.
@expede and I talked a great deal about this at DevCon.
Indeed; thanks for the fun conversations 
To extrapolate a bit, smart contracts today can be modeled as single-threaded actors. Viewing them as through this lens gives the application-layer more room to grow, and potentially ways of adding more safer and more powerful constructs over time. That’s a bit off topic of this thread, though. WRT sharding, cold storage, &c, I don’t think that users should have to do the accounting of where something lives. IMO all the of routing, message addressing, &c should happen below the application layer, and should feel like one VM, as it is today.