imperative threads vs elixir functional concurrency example

[Michael Ni]

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.

[Peter Hamilton]

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 <micha...@gmail.com> 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 elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/d3fd8aa3-cc43-46e3-85b8-ce10c7a3de8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pedro Medeiros]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAOMhEnwEi50jhFkAQMWJ6BNMzO%3D-02OK3stEvKLrQCPEWJrgVQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Pedro Henrique de Souza Medeiros
----------------------------------
Cel: +55 (61) 9197-0993
Email: pedr...@gmail.com

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

[Michael Ni]

Thanks, i'm gonna buy the book.  

[Torben Hoffmann]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/2cae5a89-3bd5-4488-a1e5-964e3455e5bb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://www.linkedin.com/in/torbenhoffmann

@LeHoff

[Onorio Catenacci]

So all this time that people have been calling my code "offensive" they were actually paying me a compliment?  :P

(I am sorry, I couldn't resist.)

--

Onorio

[Dave Aronson]

On Wed, Jun 15, 2016 at 1:24 PM, Onorio Catenacci <cate...@gmail.com> wrote:

> So all this time that people have been calling my code "offensive"
> they were actually paying me a compliment? :P

Naah, they just thought it was a munition under ITAR
(https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations).

(Yes, it can include software, if sufficiently defense-related. Most
programmers who have worked for defense contracting companies have
probably written ITAR-restrictable software....)

-Dave

--
Dave Aronson, consulting software developer of Codosaur.us,
PullRequestRoulette.com, Blog.Codosaur.us, and Dare2XL.com.

[Rich Morin]

On Jun 15, 2016, at 01:35, Torben Hoffmann <torben...@gmail.com> wrote:
> This leads to very offensive code (ie, not defensive) and a life in joy.

Sounds a lot like Avdi Grimm's take on Ruby:

PATTERNS FOR JOYFUL CODING

Confident Ruby is, first and foremost, a book about joy. It’s about the
joy I found when I first discovered how elegantly and succinctly I could
state problems in Ruby code. It’s about the joy I gradually lost as the
“real world” snuck in and cluttered my code with distracting edge case
scenarios, error handling, and checks for nil. And it’s about how I came
to recapture that joy, by employing small patterns and stylistic choices
to make each method tell a coherent story.

The structure of the book is that of a patterns catalog. But these are
not large, heavy-weight architectural patterns. These patterns are small,
most of them taking place at the level of an individual method or even a
single line of code. They are related by a single organizing principle:
removing the uncertainty that leads to code constantly second-guessing
itself; and replacing it with a confident, clear focus on the task at hand.

-- Confident Ruby
http://www.confidentruby.com/

-r

--
http://www.cfcl.com/rdm Rich Morin r...@cfcl.com
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841

Software system design, development, and documentation

[Michael Ni]

I bought the book and read through the chapter on Java threads, it mentioned several issues with the traditional threading model.  The obvious one was deadlock.  One thing that surprised me was how the JVM would reorder certain instructions.  

On page 13, the bottom code under mysterious memory.

The ordering of line 6 and 7, the JVM may optimize.

I tried running that code and could not reproduce it.  Does anyone have an example that can reproduce that issue?  If what the book says is true, it is really hard to know where to synchronize.

On Tuesday, June 14, 2016 at 7:13:07 PM UTC-7, Pedro Medeiros wrote: