3 ms·
The problem with Erlang is that it solves the wrong problem, so to speak. Reasoning about state locally (inside a procedure/function) isn't all that hard -- whi
by lomnakkus 13y ago
The problem with Erlang is that it solves the wrong problem, so to speak. Reasoning about state locally (inside a procedure/function) isn't all that hard -- which is why intra-procedure/function immutability doesn't actually get you very far. The trick in, e.g. Haskell, is that you can enforce inter-function immutability. In the end all actor-based systems end up being a huge mess of distributed/shared mutable state -- which is what we're trying to get away from. (I'm well aware that there are formalisms that can help you deal with some of this complexity, but they are a) not part of the language, and b) not practiced very widely in my experience.)
- mixedbit 13y agoHaskel doesn't address problems of distributed computing at the language level. For distributed computing you need message passing, you need to handle failures. If you do distributed computing in Haskel, you also need to build and use actor-based abstractions. It is not possible to hide distributed computation behind an immutable function call abstraction (RPC systems tried to do it and failed).
- lomnakkus 13y agoIndeed not, but that's not quite the point I was trying to make. My point was more that preemptively programming as if every single little piece of state is potentially distributed state is actually detrimental. Distributed mutable state is hard and there's no way around that other than changing the model to e.g. a reactive one -- local mutable state shouldn't be hard.