3 ms·
I found it interesting that the article mentions actors much at all for the same reason. It's pretty trivial to construct actors out of some other message pass
by heavenlyhash 8y ago
I found it interesting that the article mentions actors much at all for the same reason.
It's pretty trivial to construct actors out of some other message passing system. The interesting design choices in doing so are mostly down to the semantics in A) message passing, and B) scheduling/triggering/mapping-onto-green-threads/etc.
And for part A, all the other choices in the first three segments of the article are still effectively the choices that you've got to contend with: copying vs immutablity (bonus, COW mode, but still) vs ownership semantics.
Or to come at it from the other way: actors are far more featureful than is appropriate to directly compare to mere message passing semantics choices, because actors generally have some concept of error handling as a result of their relationship to scheduling, and that puts them on a whole different field.
- macintux 8y agoThat’s a big reason I’m a fan of Erlang: individually, its features are interesting, but collectively they form an amazing system. Greater than the sum of its parts.
- dmix 8y agoAgreed, it's one thing to have good primitives like Go channels but Erlang/Elixir provide an entire system from which to build a concurrent/async application. Things like error handling, messaging, storage, and structuring your application well for concurrency are already basically built-in into the standard approach you take building Erlang/Elixir apps.
- lugg 8y agoWhats a tldr for how Erlang handles error handling? This is something that is usually glossed over / afterthought when it is kind of a big deal in real life programming.
- macintux 8y agoThe language is built upon a few core concepts: * Processes are extremely lightweight, orders of magnitude smaller than operating system processes or JVM threads. * Exceptions should generally not be handled; instead, those lightweight processes are allowed to fail, and an external supervisor process will re-launch if appropriate. * Assertions about the state of the data are effectively enabled on every line of code, so the processes crash early, before corrupting other parts of the system. * Data is immutable, which plays a role in making those assertions happen. You could probably strip one or two of those bullet points and/or add a couple of more, but I think that captures the highlights. I'll toot my own horn. If you find that interesting, this is my favorite talk I've given about the above: https://youtu.be/E18shi1qIHU https://youtu.be/E18shi1qIHU
- dmix 8y agoIt’s hardly an afterthought in Erang. It’s a fundamental part of OTP to handle failure. Which is far easier when everything is wrapped in restartable processes with immutable state.