My Personal Tech Limbo (and Elixir vs Rust)

Another programming language battle?

Elixir vs Rust

who will be the winner?

rust vs elixir


I wanted to write this article because I need a place to release all my suppressed emotions. My brain is obsessed with programming languages. I'm in the Tech Hype Cycle and instead of deep learning real stuff I'm procrastinating in a paradox of choice, information overload and FOMO hell. I want to pick a programming language to learn and focus on it. But I can't choose. This article is the sum of all my output considerations caused by my current state of mind.

Why pick a new programming language

I have always been a big fanatic about switching from different programming languages: Ruby, Java, Kotlin, JavaScript, TypeScript, Python, C#... In the end, I always thought that the language I use doesn't matter a lot, but this thinking changed when I discovered Scala and the functional programming paradigm. I fell in love with it. After that, I started an exploration into the most obscure areas of programming niches: Clojure, Haskell, Elm, Erlang, Elixir, F#, APL, Factor... and many others.

I have always dealt with these languages passively with the consideration I never used them. But the reality was that I was stuck in the hype cycle limbo: passing from language to language without learning anything. The event that helped me to get out of this situation was joining a motivated Haskell meetup study group.

Learning the basics of Haskell was an extraordinary mind-blowing activity. The strange syntax and concepts behind Monoid, Applicative, Functors and Monad opened my mind to previously unimaginable solutions.

Lessons learned

  1. It was thanks to skilled and motivated people that I was able to break my procrastination loop.
  2. learning an alien programming language is a profound activity that can during more than a year and requires great focus and commitment.
  3. sometimes absorbing new stuff requires unlearning and unlearning is way harder than learning: What You Already Know Can Hurt You.
  4. If in my day by day I'm not exposed to different solutions, I need to make effort to find them. Only learning different approaches is worth: learn to change the way you think.


I stop myself to learn Haskell, this programming language can be a tasty drug towards an infinite internet rabbit hole but of esoteric math and category theory (I found it terrifying and interesting at the same time).

I want to learn something other, I'm looking for something more practical and similar to Haskell in the learning experience.

The problem is that now I'm in the hype cycle hell again. The paradox of choice and procrastination makes me suffer and obsessed in find motivations to pick one or the other. I want to expel some here.


I note some similarities between Rust and Haskell (generics, traits, derve annotations). It takes inspiration from the most practical parts of functional programming, but it's definitively not a functional programming language.

The main reason to pick Rust for a project is for dealing with performance and problems where you don't want a garbage collector. This characteristic makes the language in the same niche as C and C++ but with some differences: the entire language design and compiler are architected in order to release the memory and avoid any memory issues (race conditions too) at compile time.

Rust is a system programming language. It has been created by Mozilla with the goal to prevent issues in the domains of operative system and browser development.

To achieve this goal the compiler is considered an extraordinary teacher but strict like Mormons.

rust developer compiler cycle

The influence of ML-derived programming languages makes Rust extremely suitable for correctness. Rust programs do not compile if all compiler formal rules are satisfied. This feature is enormously powerful in order to prevent errors before going into production. Moreover, the design cover not only memory issues but the most common programming errors:

This can be a little bit frustrating, but compiler error messages are extremely user-friendly and well documented.

It is a system programming language, which means

Concepts like lifetime, borrow checker, memory ownership, smart pointers... are permeant in the entire ecosystem. A good resume here - rust memory management without garbage collector and here - the best rust cheatsheet ever.

Commonly, high-level programming languages are many times more focused on business logic by delegating tedious memory management tasks to the garbage collector. Rust is different from C and C++ because it is the compiler that does the garbage collector tasks for you. But all C, C++, and Rust require the developer to be aware of how memory is handled in the program.

What are the memory awareness implications?

Many choices and a lot of different ways to do the same thing.

rust choices

I am not a system programmer... my languages are Kotlin and TypeScript. Mainly I develop web applications and microservices. In my day-by-day, it is very uncommon to think about what the garbage collector does for me.

It is what I want. Am I looking for something to destroy my normal way of thinking? Right?

But also I'm looking for something practical

rust risk learning curve

If I start learning Rust, I fear the learning curve will take me into another rabbit hole. Some super cool articles scared me:

Trends, ecosystem considerations, and opportunities

I tried to follow the programming tends many times. I started to think that it was a pretty useless activity. Trends are unstable and hard to predict. When I follow trends, I become corrupted by information anxiety, which boosts my FOMO. It doesn't help me.

But in this obsessed state of mind, I collected a lot of sources of these useless trends: google trends tiobe index pypl index github stats stackoverflow hackernews jobs trends redmonk

the language seems to be particularly loved, I don't know what its means, a lot of people are interested in it but I always considered this piece of information tricky and can be easily subjected to fluctuation. Rust always ranks on average in the top 10-20 places in the most famous languages lists. However the most important factor here is not the ranking, but the incredible growth that rust has been having in recent times. Rust is cited in a cool video about OSS trends and the Crate package manager presents an anomalously large number of libraries for the language age and learning curve. It was born in 2010.

A super interesting point of view is the Jetbrain Survey. The language appears to be used primarily by hobbyists. But several articles "on the internet" (some: 1 2 3 4) write that even the big techs love Rust.

But what is the Rust niche? When we think about a DSL, the purpose of SQL is well defined. But what about Rust?

What kind of software I should create with it? Complex command-line interface, compile-time-checked and safe software, embedded software and operative systems, cloud infrastructure (such as database, DNS...), low-level library wrappers, k8s microservices, game engines, desktop applications, heavy computation software, graphic, high-performant web server, high performant parsers, protocol, and network programming... some famous projects are AWS Firecracker, Mozilla Servo, Deno, Rust for Linux, Coreutils... why I do not choose something more mature? The Lindy Effect affects any new language or technology. Only if the technology is disruptive will it be chosen and used.

Definitely, I think that the concrete purpose of the language is not well defined, the ecosystem is divided into many smaller and very different niches.

The Rust trade-off

Rust has a lot of interesting good characteristics: compiles to a single and distributable binary; it is inherently fast; it requires less memory and CPU than any other programming language; Cargo is a great package manager; the language design is modern and captures a lot of possible bugs at compile time.

But some cons are: the environment tooling isn't mature as Java; the compile time is slow, any CI pipeline needs to be optimized very well and the day-by-day development feedback or feature iteration can be negatively affected. You need to think a lot about memory. The learning curve is high and it can be difficult for a team to both hire and train new developers. Libraries may be lacking or have some gaps in stability and the concurrency is a very difficult and constantly evolving topic.


The Elixir design is the fusion between Erlang and Ruby. And I consider the Erlang design a fusion of Prolog and Haskell.

The main reason to pick Elixir is that you know and want to take advantage of Beam the Erlang virtual machine. Fundamentally Erlang and Elixir are the same single thing. Elixir improves Erlang's syntax in order to make it a less niche language and more suitable for web development, giving it a better development experience and reliability to many more users. Elixir is a functional programming language, but unlike the ML family, it is not typed and does not aim for absolute correctness or purity.

In 1986 Ericsson created Erlang with the pragmatic purpose of handling fault-tolerant and soft real-time telecommunications traffic. To achieve the goal of building fast, scalable, near-failure-tolerant network applications (see uptime), the authors had to address the hard problems of distributed systems and enclose the solutions at the core of the Bream (see the Erlang version of Greenspun's tenth rule).

Going deeper, an application written with this language is a kind of operating system that manages several distributed concurrent virtual processes that send messages to each other. These processes are lightweight, they can crash and restart in total isolation without knowing which machine is running the code or any impact on uptime. This particular architecture is called Actor Model and a particular set of libraries called OTP give the language simple but powerful structures for developing distributed systems.

is It what I want?

The 9th Circle of Erl

Reading about the Erlang community hype phase is common for people to come and go. The goal for me should be to learn something new and mind-blowing. But I'm afraid to go into a rabbit hole. What exactly is my goal? Should I reach the 5th step and move on or try to go deeper? What is the best balance between profit and investment?

Trends, ecosystem considerations, and opportunities

Again: google trends tiobe index pypl index github stats stackoverflow hackernews jobs trends redmonk

Well, the conclusions of my pointless impressions of Elixir's panoramic trends are that Elixir is a smaller niche than Rust. This may be caused by Rust's mainstream momentum, but all the data gives me the impression that Rust has more opportunities to become a relevant language than Elixir.

But I want to put another point of view on the plate of the arguments. Erlang is less affected by the Lindy Effect than Rust. Erlang in its telecommunications super small niche has been a beast for more than 30 years (Elixir is in stable mode). Elixir in web development is the new thing and web development is a saturated market of a lot of mature and effective tools. Elixir in web development is the newness and web development is a market saturated with many mature and effective tools. Once again: only if the technology is disruptive will it be chosen and used.

Personally, I think the main advantage of the Phoenix framework is the ability to be a classic MVC framework like Rails, Django, or Laravel but inherently functional and with the power of the Erlang ecosystem. This can open up a debate on the advantage of starting a project picking the functional programming paradigm, the advantage of starting day one with a less popular but potentially "easy-to-scale" application if I need it in the future...

Unlike Rust, Elixir's community effort is much more focused than Rust's. Much effort has been devoted to the Phoenix framework and the improvement of the related ecosystem.

What kind of software I should create with it? Common web applications, distributed systems, microservices, where I need fault tolerance, soft-realtime, game servers, chat servers, and heavy concurrent systems. Erlang and Elixir are used in software like League of Legends, WhatsApp, Discord, and Plausible. Types of software that are quite closer to my day-to-day.

The Elixir trade-off

Elixir benefits from the functional programming paradigm; building an application means managing data by composing small and atomic functions together using expressions such as pipe operators and pattern matching. Playing with the Actor Model is more or less like doing a system design simulation, but all in one application.

Some cons are: again, the tools aren't as mature as the most popular programming languages; the lack of a strong-type system can be useful for prototyping, but in a long run it becomes difficult to maintain. The Elixir is a niche, libraries may be lacking and experts can be hard to find in the market. The language paradigm can initially discourage, however, once the initial barrier is overcome the learning curve of the basics is not so high.


tech hype cycle limbo

My purpose here is not to choose the right tool for the right problem. But pick a topic worth exploring and studying.

They are super different types of programming languages, both of which solve very different problems and can help to reason in different ways.

Data give us the situation about trends:

  • Elixir still remains a super cool small web dev niche.
  • Rust is rising, big tech(for replacing legacy system code) and people love it. It seems to give it a lot of traction.

But trends don't matter. No matter what I choose, both are worth learning. I should just pick one and try it out. It takes less time to act than to decide between two niches that could die tomorrow. Learning does not mean that I have to become an expert in a particular technology. I should learn enough to be satisfied. And put these tools in my toolbox and move on.

The book "Pragmatic Programmer" is a magic pearl about this topic, the chapter "Your Knowledge Portfolio" is without price. I absolutely recommend buying and reading it.

YOUR KNOWLEDGE PORTFOLIO We like to think of all the facts programmers know about computing, the application domains they work in, and all their experience as their knowledge portfolios. Managing a knowledge portfolio is very similar to managing a financial portfolio:

Serious investors invest regularly—as a habit. Diversification is the key to long-term success. Smart investors balance their portfolios between conservative and high-risk, high-reward investments. Investors try to buy low and sell high for maximum return. Portfolios should be reviewed and rebalanced periodically. To be successful in your career, you must invest in your knowledge portfolio using these same guidelines.

The good news is that managing this kind of investment is a skill just like any other—it can be learned. The trick is to make yourself do it initially and form a habit. Develop a routine which you follow until your brain internalizes it. At that point, you’ll find yourself sucking up new knowledge automatically.

It’s important to continue investing. Once you feel comfortable with some new language or bit of technology, move on. Learn another one.

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas. Get familiar with object orientation, for instance, and you’ll write procedural programs differently. Understand the functional programming paradigm and you’ll write object-oriented code differently, and so on.


Now my goals have changed slightly, I stop looking for information to choose what to learn and just focus on learning that thing. I think I'll take the advice to stop learning frameworks. I want to combine niche language learning with evergreen developer skills and Leon and Joseph's evergreen developer skills.

But above all else, it was very refreshing to write this post. it helped clear my mind and I think I will continue to do so.

interesting Articles and Resources:

programming trends:
- packages number:
- jetbrain survey:
- google trends:,%2Fm%2F0dsbpg6
- tiobe index:
- pypl index:
- github stats:
- stackoverflow:
- hackernews jobs trends:
- redmonk:
- OSS trends:



- the perfect language:
- learn to change the way you think:
- rosetta code:
- billion dollar mistake:
- Make illegal states unrepresentable:
- stop learning frameworks:
- evergreen skills for developers:
- evergreen skills for developers by Leon and Joseph:
- bob the dark path:
- Greenspun's tenth rule:

- hype cycle:
- information anxiety:
- the paradox of choice:
- information overload:
- what you already know can hurt you:
- learn to learn: