4 ms·
I'm not quite at the point where I can appreciate how useful this is, because I don't really understand concurrency itself. What is a good resource from which t
by rpazyaquian 10y ago
I'm not quite at the point where I can appreciate how useful this is, because I don't really understand concurrency itself. What is a good resource from which to learn about concurrency, and especially Elixir/Erlang's approach to it?
- iamd3vil 10y agoIf you are interested in books, "Elixir in Action" is quite a nice introduction to OTP.
- macintux 10y agoFred Hebert's Learn You Some Erlang is quite approachable. http://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency http://learnyousomeerlang.com/the-hitchhikers-guide-to-concu...
- OWaz 10y agoIf you want to watch a video, check out Joe Armstrong (one of the creators of Erlang) talk about concurrency and Erlang[0]. There are a bunch of Erlang/Elixir videos [1] posted by Erlang Solutions on YouTube. [0]: https://www.youtube.com/watch?v=YaUPdgtUYko https://www.youtube.com/watch?v=YaUPdgtUYko [1]: https://www.youtube.com/c/erlangsolutions/videos https://www.youtube.com/c/erlangsolutions/videos
- vemv 10y agoBefore diving into Erlang/Elixir, I'd make sure to learn the basics of concurrency/parallelism with more basic languages such as Java, Python or Ruby. i.e. start with the easy stuff, then with that strong foundation choose as you prefer!
- dragonwriter 10y agoHonestly, learning actor-model concurrency with Erlang (and probably Elixir) is a lot easier than dealing with concurrency in the "basic" languages you list. Concurrency in Java, Python, or Ruby isn't "the easy stuff" compared to concurrency in Erlang/Elixir.
- vemv 10y agoConceptually, threads are probably easier than actors for a beginner. I'm not saying that it's easier to implement correct code with threads (in fact it's more complex), but most devs go from OO to FP, not the other way around. These days there is such an explostion of languages, frameworks, techniques etc it must be scary for a beginner. Given that, i'd advise to go by the safe (average) path.
- rubiquity 10y agoBut if you learn about concurrency via threads then you have to learn about mutexes... if you learn about mutexes then you have to learn about condition variables... and if you learn about condition variables then you have t... Well you see where this is going. I think it's important to learn about Threads, Mutexes, Condition Variables, and why sharing isn't caring, but I don't think those lessons necessarily need to come before learning about the Actor model.
- nugator 10y agoOn the other hand, if you want to sell the Actor model it might be good to first go through the complex techniques needed for trying to get concurrency right with threads.
- dragonwriter 10y ago> most devs go from OO to FP, Most devs go from OO to FP because of dominance of OO in industry (with knock-on effects on pedagogy) from sometime around the late-1980s/early-1990s until recently. Shortly before that, the same would be true of procedural to either OO or FP. And probably at one point the same would have been true of unstructured imperative to procedural. But that doesn't mean that concurrency in popular OO languages of today is easier than concurrency in Erlang/Elixir (which may be examples of functional-ish languages, which I assume is the relevance of your OO to FP statement), nor does it mean that concurrency in formerly popular procedural languages is easier than in any particular OO language, or that concurrency in unstructured imperative languages is easier than in any particular procedural language.
- sotojuan 10y agoConcurrency in those languages is anything but easy and the reason Erlang/Elixir exist.
- fgasparini 10y agoI recommend this book about concurrency: https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in...