Hi, One thing to remember - and this is really, really important - you should not, repeat, not try to mimic a threaded architecture 1:1 on the BEAM.
There is a couple of reasons for this. BEAM processes are dirt cheap - use as many as you need, but no more ;-) The Erlang philosophy of "Let it crash" aka "Fail Fast" has to be embraced. You have to embrace failure. The intersection of message passing, fail fast and supervision (The Golden Trinity of Erlang) is what makes the BEAM unique. This leads to very offensive code (ie, not defensive) and a life in joy. If you do not embrace this you will not get all the benefits of the BEAM. It might be good enough for what you do, but then you might be better off using a language with a bigger following. Cheers, Torben On 14 June 2016 at 23:55, Michael Ni <[email protected]> wrote: > Thanks, i'm gonna buy the book. > > On Tuesday, June 14, 2016 at 7:13:07 PM UTC-7, Pedro Medeiros wrote: >> >> Well I can say that there's a book about that. :D >> >> https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks >> >> It starts using some Java examples and goes deep in other types of >> concurrency model. Also there's some talks about it from the elixir >> meetups. To summarize things, when you are dealing with threads you are >> also dealing with mutable shared data that can be modified in one thread >> and affect the other one. When dealing with erlang process (actor >> concurrency model) there's no shared data and also there's no need for lock >> some variable or code execution. >> >> There's this old talk about the subject that started to open my mind >> about concurrency. >> >> https://www.youtube.com/watch?v=4o89mWFL-2A >> >> On Fri, Jun 10, 2016 at 10:01 PM, Peter Hamilton <[email protected]> >> wrote: >> >>> There are two things at play here. One is functional programming and the >>> other is the concurrency model. >>> >>> For functional programming, here are some interview questions I've >>> personally gotten that are much simpler with Elixir. >>> https://gist.github.com/hamiltop/3013ab0f9d886b813283#file-funprog-ex >>> >>> For the concurrency model, it's hard to compare. Sometimes its a lot >>> like using threads, except your system can trivially create half a million >>> of them. Other times it's wildly different and your architecture and design >>> reflect that. >>> >>> On Fri, Jun 10, 2016, 4:20 PM Michael Ni <[email protected]> wrote: >>> >>>> Does anyone have a simple example demonstrating Elixir's functional >>>> programming's benefits over a more traditional imperative threaded approach >>>> like Java? >>>> >>>> I'm looking for the same logic but shown in both, lets say, Elixir and >>>> Java to cross compare. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "elixir-lang-talk" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-talk/d3fd8aa3-cc43-46e3-85b8-ce10c7a3de8e%40googlegroups.com >>>> <https://groups.google.com/d/msgid/elixir-lang-talk/d3fd8aa3-cc43-46e3-85b8-ce10c7a3de8e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-talk" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-talk/CAOMhEnwEi50jhFkAQMWJ6BNMzO%3D-02OK3stEvKLrQCPEWJrgVQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-talk/CAOMhEnwEi50jhFkAQMWJ6BNMzO%3D-02OK3stEvKLrQCPEWJrgVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Pedro Henrique de Souza Medeiros >> ---------------------------------- >> Cel: +55 (61) 9197-0993 >> Email: [email protected] >> >> Beautiful is better than ugly, >> Explicit is better than implicit, >> Simple is better than complex, >> Complex is better than complicated. >> >> The Zen of Python, by Tim Peters >> > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-talk/2cae5a89-3bd5-4488-a1e5-964e3455e5bb%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-talk/2cae5a89-3bd5-4488-a1e5-964e3455e5bb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- http://www.linkedin.com/in/torbenhoffmann @LeHoff -- You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CABf3pC%3DChFa8JDv695-vuFc6E1KaycEeTN-SrbAN_u-Bu15rkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
