Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
masklinn
Is this you? Claim Profile »
1 year ago
in A followup on Concurrency within Python on jessenoller.com comments
> I doubt they envy the syntax or complex nature of it
What syntax wouldn't there be to envy, and which part of Erlang's concurrency model is complex?
First point: Erlang's concurrency requires 2 primitives: a "send message to process" and a "retrieve message from mailbox". The first one is straightforward and trivial, the second one is a bit more complex (it needs the ability to have timeouts, and while pattern matching makes filtering/fetching messages extremely straightforward it may be more complex to handle that without PM). The send/receive syntax is one of the best parts of erlang's syntax: straightforward, short and to the point. What isn't there to envy? Yes we could add `spawn`, but that's not specific to erlang-style concurrency.
Second point: the complexity. In all of my experiments, Erlang-style concurrency was infinitely simpler than e.g. java-style concurrency, even with java.util.concurrent (1.5's, we haven't switched to 1.6 yet) for various reasons:
* A single concurrency structure (which can be built upon to e.g. supervisor tree, but at its core Erlang only has "send a message, receive a message")
* Unconstrained resources, there is no need to bother with thread-pooling and other tripe/implementation details in Erlang. If you need a process, just spawn it and let the runtime take care of its allocation and scheduling
* Synchronous/sequential erlang and asynchronous/concurrent erlang are clearly separated with function calls on one side and messages on the other one, message sends don't look like function calls and reciprocally.
* Finally, erlang has the tools to handle massive concurrency, in order to introspect and debug a system that can have thousands of running processes.
So I'd like to know more about what you consider to be the syntactical or complexity problems of shared-nothing message-passing concurrency *compared to shared-memory "java-style"* concurrency.
What syntax wouldn't there be to envy, and which part of Erlang's concurrency model is complex?
First point: Erlang's concurrency requires 2 primitives: a "send message to process" and a "retrieve message from mailbox". The first one is straightforward and trivial, the second one is a bit more complex (it needs the ability to have timeouts, and while pattern matching makes filtering/fetching messages extremely straightforward it may be more complex to handle that without PM). The send/receive syntax is one of the best parts of erlang's syntax: straightforward, short and to the point. What isn't there to envy? Yes we could add `spawn`, but that's not specific to erlang-style concurrency.
Second point: the complexity. In all of my experiments, Erlang-style concurrency was infinitely simpler than e.g. java-style concurrency, even with java.util.concurrent (1.5's, we haven't switched to 1.6 yet) for various reasons:
* A single concurrency structure (which can be built upon to e.g. supervisor tree, but at its core Erlang only has "send a message, receive a message")
* Unconstrained resources, there is no need to bother with thread-pooling and other tripe/implementation details in Erlang. If you need a process, just spawn it and let the runtime take care of its allocation and scheduling
* Synchronous/sequential erlang and asynchronous/concurrent erlang are clearly separated with function calls on one side and messages on the other one, message sends don't look like function calls and reciprocally.
* Finally, erlang has the tools to handle massive concurrency, in order to introspect and debug a system that can have thousands of running processes.
So I'd like to know more about what you consider to be the syntactical or complexity problems of shared-nothing message-passing concurrency *compared to shared-memory "java-style"* concurrency.
1 reply
I agree with you on the power of Erlang's model - however I think the barrier-to-entry of Erlang is why it continues to largely be a niche language. If Python were to adopt some of the theory behind what Erlang is done, I would be happy.