How to show Elixir to Scala Programmers?

I’m preparing presentation about Elixir language - for group of developers, mostly Scala and few Clojure. All of them are very experienced so basic like syntax or dependence on Erlang will take no more than 5 slides together. But what should I show next?
I think about Processes and Nodes? communication between them or even hotswapping the code. Good example I found in Programming Elixir book: Supervisor restarts the process with current state - it’s good example for Fault tolerance.

Maybe something other? Any advices? What do you think, should I show these guys (and gals :slight_smile: ) on this presentation?


The biggest difference between Scala (with Akka) and Erlang is that
Erlang’s processes are pre-emptively scheduled. No more worrying about
blocking threads, etc. If one process does a blocking operation the VM will
simply schedule another one until that one unblocks.
This is a huge difference in how you write your programs - you rarely see
any constructs to handle async code in Elixir/Erlang, while there are a lot
of them in Scala.

Having said that, my experience with Scala is extremely limited.



Can you explain a bit more what it means for the BEAM VM to be pre-emptive? My understanding is that a process has a set execution window. This execution window is 2,000 reductions / function calls, after which the scheduler will allow another process to start executing. Is this correct? What happens if the first process is not done before being pre-empted?

(Note: I hope this is not hijacking the thread, but it might allow @marioosh to tailor his presentation if he decides to present this topic).


It will simply be paused. For a great tour of the BEAM’s features I recommend watching:

  • Description Elix/Erlang ecosystem like Phoenix/Ecto
  • Erlang Actor Model
  • Build Tools Mix
  • Testing tools/Monitoring Tools
  • Some IDE supports (Java/Scala guys love IDEs :slight_smile: )

I think Scala developers are mostly interested in :


This is another resource that was very useful for me to understand the fundamentals of what the BEAM can offer that the JVM cannot.


thanks for advice :slight_smile: thanks also for link to that document, very interesting reading.


One thing is that Scala has a reputation of being a WORN-language.
WORN == “Written Once, Read Never”. This probably comes from its hybrid OO-FP nature.
At we work, we go the golang way for microservices to avoid having to maintain Scala.
IMO, Scala needs a language clean up and compaction.
If Java is “C”, then Scala got the “C++” feel. Scala is the “red pill” for the Java “matrix”.
If I were you, I would emphasized readability, concurrency and productivity.


How do you like programming in go? I heard it is dead simple :slight_smile:

Moving a team from Scala to Golang

Do you think Elixir/Erlang could be better solution for GO? :slight_smile:

The problem with Scala is that you can do the same thing in many ways and there many programming styles. It is good
before starting coding to agree on some standard with team what can be used and what not. Another problem is junior developer could not understand code of senior developer. The problem become to maintain code. The learning path for Scala can be quite long. I am not saying that Scala is bad language but can be complicated to maintain.

The evolution of learning Scala:


A few things off my heads in anwering your questions:

Yes. It’s very simple and clean. I supposed you can do some limited FP in Golang if you are disciplined since functions are first class citizen in Golang. But its mostly OO.

The built-in language support for remote processes and concurrency is powerful via OTP. Scala/Golang are probably positioned as a general purpose(GP) language, with expectation that any support for distributed concurrency to come from external support libraries or frameworks. So if you are going to do small toolings, Elixir is an overkill, Golang is a better fit . But for distributed, concurrent, fault tolerant system, Elixir wins over Golang easily as a one stop-shop solution.
I see Golang as sitting between the realms of C and C++ with garbage collection thrown in.

Here is the irony : Java is result of reaction to C++ being complex; now we have Scala being a reaction to Java being …(fill in your reasons here). Remember that TCO(Total cost of Ownership) of a software is 90% maintainence. That means readability. So we are back to the matrix ala C++, maybe worse. So if we have trouble reading code, how are we going to confidently fixor refactor something?. It will be blocks of hieroglyphics waiting to be deciphered at leisure, assuming that you have the time… :sunglasses: Java 8 functional features also suffered from readability if used in undisciplined ways :


The future can be something like / => build program as a graph flow. This is only my prediction :slight_smile:


I refer to this as the “multi-paradigm curse”. The intended benefit of a multi-paradigm language is to offer a range of solution paradigms where hopefully one is the most appropriate for the problem domain. In reality the chosen solution paradigm typically is the one the programmer is most familiar and comfortable with - independent of whether or not it is actually suitable to the problem domain (which is why I take issue with using Scala as just a “better Java”).

More recently Scala has had some setbacks with LinkedIn “minimizing their dependence on Scala” (in favor of Java 8 :rolling_eyes:, etc.) and Raffi Krikorian stating that in hindsight he would “use Java and not Scala as part of [the Twitter] rewrite” (OReillySACon 2015). To a certain degree language choice seems to be often driven by the cheap/ready supply of developers rather than suitability to the problem domain.

I imagine that Scala developers would feel a bit apprehensive about giving up the safety net of static typing, so they might want to know about what typespecs and Dialyzer have to offer (and what the limitations are).

Also given that their JVM-based infrastructures and libraries aren’t going anywhere, they would likely be interested in available integration options, e.g. Jinterface, using products like RabbitMQ, etc.

A receptive Scala programmer may be interested in this blog’s account of Functional Programming in Scala being used to learn Elixir.


here’s a hotly debated link on Java vs Scala just this week(it gets really ugly fast):

I think Elixir stewardship could use some lessons learned from Scala:

  1. Keep Elixir small and essential.
    -don’t create a Big FP language, loaded with a plethora of kitchen sink features;

  2. Be its own language.
    -don’t tie to Erlang’s past or limitations

  3. Keep Elixir TCO down
    -(readability, flexible, extensible)

  4. Provide great API docs and support.

  5. Keep Elixir off IvoryTowers smugs
    -welcome little guys and big guys to use FP


Yo know this article is on Java Zone (One side perspective) … but there is some True.

Something from Java World … :slight_smile:

I think it is hard not to tie to Erlang as Elxir runs on Erlang VM.


Golang today took 16th place; Scala at 33th…
The main lesson is that a smallish language that is clean, readable and flexible can win :slight_smile:

1 Like

I am waiting. GO is nor clean, nor readable nor flexible. Quite the contrary. Is it better than a lot of other choices? Yes maybe, but they are all awful. (Java, C, Cpp., .Net… nope ty !).

I bet we will get a lot of “why we should have avoided Go” in the coming years.

But well i am a Go hater so YMMV.

Elixir for Scala programmer : Concurrency and FAULT TOLERANCE. I can’t strengthen that enough.

Also hooks for nearly everything, and the fact that even if it is dynamic, the VM is meant for FP.


This is definitely one of the most difficult things when designing a language/system. You want it to be powerful and it is so easy to just keep adding features. How do you get a minimal set of the right features which allow you to build everything else nicely on top of them? Dijkstra has a number of good quote about this, for example “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”

There is not much you can do about this, Scala has the same issue with Java. You just need to keep it at a reasonable level and explain what comes from where, and why.

Can’t argue with these points.

Whatever you do you will always annoy someone. :smile:


Maybe commands higher salaries :slight_smile:

Perhaps because they feel they are getting more.

1 Like