3 ms·

Isn't Erlang the language that you can edit/patch while it is executing? I think hard typing would be extremely difficult in that kind of environment.

by tniemi 8y ago

abstractbeliefs 8y ago
It is, but you can still running static analysis tools on written code before executing a code switch. The key thing is that you track the changes applied so you understand what's happening. The nice thing about erlang though is that the nature of the message passing interface and pattern matching means that you can get relatively understandable interfaces.
koala_man 8y ago
Someone should correct me if I'm wrong, but I don't think that this is a special feature of Erlang. It's done by writing your handlers to accept a closure to use for future requests. It's not inherently different from doing this in Java: if (req.isUpdate()) { handler = Class.forName(req.getUpdateName()).newInstance(); } else { handler.handle(req); } It's way easier when you have message passing and every level is set up to restart on crashes, but I don't think anything necessarily stops you from doing the same in any other language.
- bitwalker 8y ago
  A bigger problem is this: - Given a distributed Erlang system with two nodes, where both nodes are running the same release; - Given the same process (Erlang thread) on both nodes, running the same code (i.e. a GenServer backed by the same module) - Given a new version of the release is being applied You can't assume that the two processes will be upgraded at the same time. This means that messages sent between those processes may violate the types expected by one version or the other. Furthermore, in Erlang, any process can send a message to another process, so there is no way to enforce that the data a particular `receive` expression gets will even be a type defined in the code it is running. Furthermore, even on the same node, during an upgrade, some parts of the system are still running old code, while some parts are running new code, so it isn't even specifically about distribution. There is a whole area of type system research around session types, which are designed for more or less this use case, but from what I've seen, none of them handle the case of arbitrary messages, or the case where system upgrades are being rolled out and old code may receive messages from new code. I still think there is a place for a type system in Erlang/Elixir, but it would have to deliberately ignore process messaging at the very least, at least until a type theoretic solution is available.
  - lpghatguy 8y ago
    You're still going to run into the same problem between old/new processes and message types mismatching with dynamic typing, it's just going to be implicit. I think that this ideas generalizes pretty well. Just because a language doesn't have explicit types doesn't mean types don't emerge organically. Assumptions will still be made about certain fields existing, there's just no guarantee that the assumptions still hold!

Isn't Erlang the language that you can edit/patch while it is executing? I think hard typing would be extremely difficult in that kind of environment.

by tniemi 8y ago

Isn't Erlang the language that you can edit/patch while it is executing? I think hard typing would be extremely difficult in that kind of environment.

abstractbeliefs 8y ago

It is, but you can still running static analysis tools on written code before executing a code switch. The key thing is that you track the changes applied so you understand what's happening. The nice thing about erlang though is that the nature of the message passing interface and pattern matching means that you can get relatively understandable interfaces.

koala_man 8y ago

Someone should correct me if I'm wrong, but I don't think that this is a special feature of Erlang. It's done by writing your handlers to accept a closure to use for future requests. It's not inherently different from doing this in Java: if (req.isUpdate()) { handler = Class.forName(req.getUpdateName()).newInstance(); } else { handler.handle(req); } It's way easier when you have message passing and every level is set up to restart on crashes, but I don't think anything necessarily stops you from doing the same in any other language.

bitwalker 8y ago
A bigger problem is this: - Given a distributed Erlang system with two nodes, where both nodes are running the same release; - Given the same process (Erlang thread) on both nodes, running the same code (i.e. a GenServer backed by the same module) - Given a new version of the release is being applied You can't assume that the two processes will be upgraded at the same time. This means that messages sent between those processes may violate the types expected by one version or the other. Furthermore, in Erlang, any process can send a message to another process, so there is no way to enforce that the data a particular `receive` expression gets will even be a type defined in the code it is running. Furthermore, even on the same node, during an upgrade, some parts of the system are still running old code, while some parts are running new code, so it isn't even specifically about distribution. There is a whole area of type system research around session types, which are designed for more or less this use case, but from what I've seen, none of them handle the case of arbitrary messages, or the case where system upgrades are being rolled out and old code may receive messages from new code. I still think there is a place for a type system in Erlang/Elixir, but it would have to deliberately ignore process messaging at the very least, at least until a type theoretic solution is available.
- lpghatguy 8y ago
  You're still going to run into the same problem between old/new processes and message types mismatching with dynamic typing, it's just going to be implicit. I think that this ideas generalizes pretty well. Just because a language doesn't have explicit types doesn't mean types don't emerge organically. Assumptions will still be made about certain fields existing, there's just no guarantee that the assumptions still hold!