How Elixir compares with Typelevel Scala?

I know a little of Elixir and apparently I’ll be moved to a Scala team at the company that I’m working by the end of the year. The codebase is pretty much Typelevel based and even having a little of knowledge of FP, from Elixir, that codebase is completely unreadable for me.

What I’m wondering is, Elixir is less functional than Typelevel Scala? Or this complexity is just the nature of a heavily statically typed FP language?

It’s astounding how simpler Elixir is compared to Typelevel Scala.

1 Like

Regardless of the flavour of Scala in question, in my opinion, Elixir (and Clojure and even ML cousins) are simpler than Scala.

With Typelevel Scala do you mean heavy usage of the Cat family of libs? If that then I’d say I had the same feeling. Other than Elixir I worked with Clojure and a little F# but I felt completely humbled when I saw some of those LoCs

Scala was (is?) my programming language for year 2024 and I wanted to get ahead of myself and start reading the Cats and the Red book but I got back to learning the basics as I didn’t quite get what they were coding on. I guess it’s the category theory influence that makes it appear tough?

I am tagging @yawaramin here since he is my go to person for all things Scala who also knows ways of Elixir. Maybe he can add some helpful info here.

1 Like

Interesting thread! I would say they have different philosophies.

Elixir/Erlang/BEAM philosophy is that runtime errors will happen and we have a robust framework in place to deal with them. But also it is nice to not lose productivity due to typos and other silly mistakes, so let’s add some level of simple typechecking support (at least for the time being, more in the future).

Typelevel Scala philosophy is that we can build our programs by plugging together small, ‘reasonably safe’ lego pieces of code and turning ‘effects’ into first-class values in our programs. Effect management is a very important part of this philosophy–primarily I/O, but also mutation, randomness, cancellation, etc. If we model each effect as a value (a description of what will happen at runtime), we can construct our programs as just different combinations of values–something programming languages are very good at.

Some people do argue that Elixir is less functional than Typelevel Scala because it doesn’t control effects. I don’t agree; I believe Elixir fulfills all the criteria (in my definition) to be a functional programming language. But I also think at a certain point arguing semantics is not that useful. One thing I will remind people is that all the ‘complexity’ may be seemingly overkill, but often we are not using raw Cats IO, we are using higher abstractions like fs2 streams. See eg Fs2

With a few lines of code, you can run streams that handle I/O, error-handling, cancellation handling, safe resource disposal, parallelization, retries, and many other abilities. You can of course do many similar things with Elixir, but due to the power of the type system, in Typelevel Scala code it’s often very plug-and-play:

The pattern of Network[F].server(address).map(handleClient).parJoin(maxConcurrentClients) is very common when working with server sockets.


The selling point of scala, at least in theory, is that it combines all features of OOP and functional programming. Before I found out about elixir, I found akka actors a extremely nice abstraction, as they are a copy of erlang processes.

I revisited the language about 6 months ago and I must say that I am not impressed, for example their implementation of monads as collections and usage of for comprehension in the way we use with in elixir is hacky to say at the very least.

I guess you would usually use scala when you have to interact with existing java code and want to make your project use some of the more advanced FP features, even though I would argue that Kotlin is a much better alternative these days, you have there finally a nice abstraction for concurrency and the syntax is much nicer, even if you don’t have more advanced FP features.