I come from Java background and have been using elixir professionally for sometime. I wonder why are things in elixir so simple. Is it too good to be true?
Take for example to harness the benefits of functional programming one needs so many constructs to for example help to engage and release resources in a safe manner, manage errors and so on. See https://arrow-kt.io/
In elixir (erlang) there’s basically processes and that’s it. Genserver, broadway and so on are all built on top of processes.
Is Elixir not able to do somethings that the jvm can do? Or is it because of the let it fail design that keeps things a lot more simple than trying to keep everything under control in the case of using jvm?
5 Likes
While I’m no expert in the topic, Elixir is a bit more of a higher level language than Java. Perhaps this is a bit of hyperbole to put it this way but I would say Elixir (Erlang… BEAM really) is particularly good at what it’s good at (almost magical), like concurrency and fault tolerance, while it is particular bad at what’s it’s bad at, like number crunching and general CPU heavy workloads. I wouldn’t say it’s too good to be true, just that there are tradeoffs and is not suitable for all needs. This is why NIFs are first class.
Perhaps someone else can give a bit more involved answer but I felt like answering, lol.
6 Likes
You might be witnessing how much easier it is to code with FP and not with OOP / imperative code.
In Elixir and other FP languages you can isolate almost perfectly what does what, what does it affect, where and when.
When I was a Ruby on Rails dev before picking Elixir, my teammates could just overwrite almost anything they wanted with global variables and monkey-patching Ruby itself. In Java before that, they could modify 30 lines of XML and have half the application use different dependencies (via the over-glorified dependency injection frameworks).
In Elixir you are assembling a LEGO. In OOP / impetative languages you throw stuff in a giant cauldron until it starts emitting the right smells. 
And to be fair to all sides… not everyone is good at assembling LEGO. A lot of people prefer to be witches and warlocks.
16 Likes
I think this goes back to Erlang. Citation required but if I remember correctly, one of the goals was minimizing the amount of code required to implement business logic. If you think of all the things you don’t have to think about because of the constraints the runtime provides to you (e.g. base set of only immutable data structures, only 1 way to do concurrency and designed very well, etc), it relieves you from having to think about a whole lot of details that is required in other languages.
Like with Java, it feels somehow both too low-level and too high-level at the same time with the concerns you need to keep in mind. Then once it comes time to actually do business logic, you have OOP nastiness like covariants and contravariant sub typing issues.
We’re using arrow-kt at my current job and I wondered the same thing. Why is this so dang complex. I think part of it ties into what I said above, these libraries have way more things to consider since the runtime doesn’t provide enough constraints around implementing high level features.
5 Likes
Also, Erlang coming from industry rather than academia or someone wanting to design a language with fancy constructs means it is great for actually getting things done. Some other FP languages have a much higher cognitive and syntactic load.
14 Likes
Fault tolerance was a core feature in the design tradeoffs made early in Erlang for use in telephone switches. It ends up that ability to limit the blast radius of a failure is useful in other types of systems too!
If you’re interested in digging deeper Joe Armstrong wrote A History of Erlang. His Ph.D. thesis is also a wealth of knowledge, but it’s much longer.
11 Likes
Im comparing elixir FP and Kotlin FP. Perhaps i am just witnessing different levels of FP? Take for example Resource | Arrow. The first line says “Allocation and release of resources is not easy”. But on Elixir (Erlang) it seems simple enough 
3 Likes
I was also thinking along the same lines. Wondering if things seem simple because the erlang vm does a lot more heavy lifting compared to jvm (at least with respect to concurrency and fault tolerance)
Any idea when ‘A History of Erlang’ was published?
(I couldn’t find a date in the paper)
The paper had a copyright year of 2007 (the end of the introduction, year only).
Here is the ACM page for the paper: https://dl.acm.org/doi/10.1145/1238844.1238850
3 Likes
I’m with @sodapopcan
If you find Elixir too good to be true, you are probably just doing something that the runtime was particularly designed to handle.
If you find Elixir too good to be true, I will make the following guesses about your business:
- I’m going to guess your application receives some kind of network requests and that you are IO bottlenecked in responding to most of those requests.
- I’m going to guess that you care more about the P95 latency of your requests than your P50 latency.
- I’m going to guess that you care more about keeping your P95 latency usable than you care about reducing your cloud spend by 20%.
- I’m going to guess that your business gets more value from uptime than from a lower P50 latency.
- I am going to guess that in the context of the background jobs your system is performing, your business gets more value from higher throughput and higher latency than lower latency and lower throughput for the same $.
- I’m going to guess that your business spends more money in engineer paychecks than on cloud or on-prem server resources.
- And lastly, I’ll assume that if your business has a really good quarter and your CFO approves an increased engineering budget, that your recruiters and hiring managers do not get tasked with hiring more than 200 engineers in a single quarter. (this is the only non-runtime thing on this list, this is actually about the language and it’s adoption curve)
If these are the trade-offs and constraints that your business placed on you, and you are on a runtime that makes different trade-offs, then it would seem too bad to be true to have to try and design a system that prioritizes these things.
3 Likes
There’s that quote: “Erlang makes hard things easy and easy things hard.” I think Elixir softens the edges of the latter, although I’m not an Erlang expert. It certainly makes some things less verbose.
I always loved this about Erlang and it’s funny how many uninformed people think it’s a convoluted academic language. On the contrary, I feel it could be a poster child for Boring Technology.
4 Likes
Don’t be too optimistic. Hardest thing in Elixir is to find a job.
13 Likes
This topic reminds me of my previous project where we had a security audit mainly for our payment system and I heard that the people asked “Where’s all the code?”. That’s it, that’s all the code there is! 
None of them had read Elixir before but they all enjoyed it and said it was really simple to understand. Moments like that make me appreciate Elixir even more.
3 Likes
Kotlin is not a bad language (from the point of view that you have 100% interoperability with java) but no matter how many features from FP it will have, it will never become a true functional language, this is the same as saying that JS is a functional language if you use a library that has functional language constructs.
There is also the important point mentioned above by others about who designed the language, kotlin was designed by folk that works on tooling for the IDE and that can be felt everytime you have to dive beyond basic language constructs and IMO this is its greatest weakness, as those are extremely peculiar and have almost zero documentation, not that kotlin documentation is good to begin with.
3 Likes
Talking about the history of Erlang, I found this video very interesting and fun.
“Erlang: The Movie”
4 Likes
Thanks, I love this video!
This is really interesting… and the Mike + Joe + Robert phone simulation awkwardly sounds like an IT crowd episode 
1 Like
No small part of this contrast is that if I don’t have full control over who my colleagues are (and who does?) I would much rather deal with some lego assembly problems vs unholy rogue potions/spells 
1 Like
I am, of course, obligated to post a link to the sequel and perhaps more appropriate for the Elixir crowd!
1 Like
And I feel equally obliged to say “Thank you for letting me know about it!” 
1 Like
