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).
PS
How do you like Scala? 
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)
2 Likes
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 = trueNo. 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. 
2 Likes
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: http://eta-lang.org/
The syntax looks âclean-shavenâ and might be a worthy competitor to Scala.
2 Likes
Scala has a lot of meta-programming capabilities that the usual FP language is entirely incapable of though, but yep, looks like normal FP. 
Looks great compared to Scala 
You made my day happy.
I see it is compatible with Haskell.
compatibility with GHC 7.10.3âs Haskell.
Article
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.â
2 Likes
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
