How to show Elixir to Scala Programmers?

Some useful lessons that can be learned ^^^

1 Like

Having recently learned Scala, I felt the pain of lacking ubiquitous pattern matching as in Elixir. This is a major strong suit of Elixir that is just another language feature in Scala.

I cringed when I learned that in Scala you can’t do something like the following, i.e. use the same name more than once in the same pattern. In Elixir, the following code is perfectly valid, but Scala will throw an exception.

{a, a} = {"one", "one"}
1 Like

val (a, b) = (“one”, “two”)
This creates two variables a = “one”, b =“two”. You can’t have 2 variables with the same name.

In Scala you need to implement destructor (unapply method) to be able to get data in pattern matching (by default all case classes have this method implemented).

How do you like Scala? :slight_smile:
My impression was more I was learning Scala I had more enough. I finally gave up and started learning Haskell (and it looks much nicer to me)


Thank you for the blog article link. I didn’t know I could pattern match in more places in Scala, especially given the sparse documentation.

Yes, “you can’t have 2 variables with the same name.” Yet in my example above, the names point to the same value, so why not allow it? Of course, {a, a} = {"one", "two"} would not match in Elixir either!

The power of {a, a} = {"one", "one"} is in further enforcing the structure and matching on a particular case of the data. And Scala doesn’t seem to let you do this without some rigamarole. My guess is there’s an underlying JVM reason for not allowing it.

something like this?

scala> val a = 1
a: Int = 1

scala> (a, a) match {case (1,1) => true}
res0: Boolean = true

No. In your example the pattern is (1, 1) not (a, a). Like this:

scala> val tup = (123, 123)
tup: (Int, Int) = (123,123)

scala> tup match { case (a, a) => a }
<console>:9: error: a is already defined as value a
              tup match { case (a, a) => a }

scala> tup match { case (a, b) => a }
res1: Int = 123

scala> val (a, b) = (123, 123)
a: Int = 123
b: Int = 123

scala> val (a, a) = (123, 123)
<console>:8: error: a is already defined as value a
       val (a, a) = (123, 123)

However, in Elixir:

iex(2)> {a, a} = {"one", "one"}
{"one", "one"}

This kind of so-called structural pattern matching is something that Erlang (and by extension, Elixir) inherited from Prolog, in which the first Erlang interpreter was built (before the BEAM was made).

interestingly, I believe it also does not work in Haskell. Going back to Haskell after having used Elixir I realized how natural it feels to use it. If it works or not depends on how the pattern matching (the unification) algorithm is built.

1 Like

Haskell is more pleasant to use than Elixir?

Uhh, this might be controversial here, but I’d say yes. ^.^

The reasons, and these are my own:

  • I find the code more readable (if you do not abuse operators, hence why I prefer OCaml over Haskell since OCaml tends to abhore operator overloading, |> is one of the few it has built-in after all).
  • It is typed, I know that if it compiles that at least my ‘code’ is correct (and at least some of my logic too!).
1 Like

Why companies avoiding haskell? What about the actor model?

Haskell/OCaml has Actor-model libraries, that is not the really good stuff about Elixir/Erlang/OTP though, and that is the reliability and throughput guarantees. Until OCaml/Haskell has those (or they can compile to the EVM directly) they will not replace Elixir/Erlang for most of my server daemon usages. :wink:


Ok this won’t work. If you want something similar in Scala

tup match { case (a, b) if a == b  => a }

But yes it works different than in Elixir.

1 Like

We have a new kool kid on the block: Eta, a new FP language on the JVM:
The syntax looks “clean-shaven” and might be a worthy competitor to Scala.


Scala has a lot of meta-programming capabilities that the usual FP language is entirely incapable of though, but yep, looks like normal FP. :slight_smile:

Looks great compared to Scala :smiley:
You made my day happy.

I see it is compatible with Haskell.

compatibility with GHC 7.10.3’s Haskell.


1 Like

I like the syntax, but one of its strengths is also a huge weakness – it runs on the JVM.

I was a huge Scala fan in a group of Java devs, but one day it occurred to me that most of the problems we have with applications are problems with the JVM. The lure of using existing libraries is great, but at the end of the day you won’t get past the instability of the JVM.

I had looked at Erlang years ago, and the stability of the BEAM looked great, but I didn’t have a good FP background and I knew that if I had trouble with the syntax, I’d never convince anyone else to look at it. When I found Elixir a year ago, I rejoiced!

1 Like

Oooh I have stories from my past life working on the JVM, like having the JVM JIT optimize some bit-twiddling math into nonsensical instructions that caused a segfault (bug was reported and it was fixed in Java 1.8) and of course the hell that is the GC on the JVM… >.<

1 Like

Like only being able to use 16GB max heap size on a 32GB server.

Here is a new twist on Scala:

The main thing that I got out of above article is: readability,maintainability and documentation.
That translates to steep TCO(total cost of ownership) of the code base.

“…As it turned out, more flexibility led to devs writing code that others actually struggled to understand. It would be tough to decide if one should feel ashamed for not being smart enough to grasp the logic, or annoyed at the unnecessary complexity. On the flip side, on a few occasions one would feel “special” for understanding and applying concepts that would be hard for others. Having this smartness disparity between devs is really bad for team dynamics, and complexity leads invariably to this.”


I get that arcane use of syntax can make some things unnecessarily “clever” but

Isn’t this getting precariously close to using the existence of smart-ass coders to justify pandering to the lowest common denominator?

1 Like