I don't think that's really true. The things that make BEAM good at distributed systems like processes and network "translucency" (because let's face it, no network is transparent) are all built into BEAM itself, not OTP. OTP sits a layer or two above those features and certainly is great for building distributed systems. But you could build a distributed system on erlang or its brethren without using OTP at all.
> > As I understand it, OTP is (among other things) a specific distributed framework.
> I don't think that's really true.
But, nothing you said contradicts it: it just argues for why BEAM is still a good platform for building distributed systems on even without OTP, not anything about OTP not being a specific distributed computing framework.
>> The things that make BEAM good at distributed systems like processes and network "translucency" (because let's face it, no network is transparent) are all built into BEAM itself, not OTP.
Maybe I'm in the minority but I read that as a direct contradiction.
I'm not sure what definition of a "distributed framework" you're working from, but if you're going to apply that label to something you ought to at least know what aspects of it specifically target the distributed use-case, and if it doesn't add anything to make the "distributed" part of that easier, then you can't very well claim its a distributed framework.
OTP is a platform for state management and fault tolerance. Everything "distributed" is already present in BEAM.
You know, I'm going to have to walk it back a bit. They don't get a lot of press, but there are aspects of OTP that address distributed applications. Mea culpa.