What to learn first - Rust or Elixir?

What learn first? Rust or Elixir

Hi Elixir community!

I’m here because i want learn a new language. I’m a junior developer and mainly i develop a microsevices web app with spring-boot, rabbitmq and Kotlin.

I don’t want a discourse rust vs elixir, it isn’t my intention because i want learn both.

But my problem is:
With the precondition of a deep focus on only one language for two years,
what is the language give me greater value to learn first?

I pretty know about Elixir and Rust, they have very different purpose (if i forgot something, please post it in this discourse):

  • Rust is a compiled strong typed language, inspired by the most healthy part of functional programming, developed for: not having garbage collector, high performance requirements, native concurrency facilities, safety and correctness thanks to amazing compile time verifications and advanced concepts named Ownership, Borrowing, and Lifetime.
  • Elixir is a functional non typed language developed on top the BEAM virtual machine.
    Fundamentally Elixir is Erlang with a particular focus on web development and in a improved developer user experience.
    Erlang is created by the Ericsson company in order to handle fault tollerant and soft realtime telecommunications traffic. An application written with this language is a kind of operating system that manage several number of concurrent and totally isolated virtual process that send message each other. This particular architecture called Actor Model and a particular framework called OTP give to the language easy but powerful facilities to develop distributed system.

Now my question is:

According to your expectations of the evolution of the web development world,
what is the most valuable skill to learn in the next two years? Rust or Elixir? and Why?

please you don’t give to me the jolly answer: it depends by what you want. You give me your first, not too reasoned predictions/expectations.

thanks for your time.


for web development, Elixir.


I just started learning elixir, but I code for about 7 years. My suggestion is to avoid this idea of “locking” yourself to only learning ine specific language. A language is just a tool. Some tools are better for some jobs than others.

My suggestion is to find what you want to accomplish first, then you think about what tool to use. Try to learn the main concepts of both and when you find a good project, then you can use the one that does the job better


two completely different language archetypes and use cases. if you’re doing web go with elixir, if you’re doing serious number crunching do with rust. but they are definitely not interchangeable. it’s like comparing c++ and ruby.


Do you want to enjoy the learning process or do you like being frustrated at every turn? Rust is great in many ways but the learning curve is steep. For almost 3 years I battled the compiler before I was able to write simple programs without dealing with lifetime and type errors at every turn. The ecosystem around rust, especially for web development, is both immature (almost nothing is at 1.0) and sprawling. Whereas Elixir has Phoenix, Rust has warp, actix, rocket, gotham, tide, tower, thruster, roa, rouille, surf, and on and on. Actix and Rocket are the more prominent, to be sure, but neither is really an accepted default solution.
I am just getting started with Elixir but I can tell you the experience so far has been much more enjoyable. Having a few standard options beats a million options or having to reinvent the wheel yourself.
Both languages seem to have great learning resources available. Documentation is a priority for both ecosystems. The Rust users forum is friendly and helpful, as this forum has been.


In my opinion, Elixir. It will change the way you think about problems and open your eyes to things are aren’t paying much attention (most likely) yet.

I haven’t seen that type of impact with Rust.

1 Like

I’m sure it depends on your background. Having no formal comp sci training, my experience with Rust really did open my eyes to a lot of things such as the choice of data structure, why immutability matters for safety/correctness, and of course ownership/scope. For all the frustration it caused me I am indebted to the Rust project for a real growth in my skill and understanding. Whether focusing on another language would have had the same impact I cannot say.


Both elixir and rust will open your eyes to new things. I recommend learning both, but for the web case start with elixir. With rust I started with a “simple” cli tool. I say simple with just a little bit of humor because if you’re a rust noob, like I am, you’ll likely fight the compiler until you learn the rust way. I think elixir and rust complement each other nicely and each has super powers.


Learn Rust. I love Elixir, but understanding what happens at a low level is more important for your career than learning a language you may never get to use for a production service. Just learning Rust teaches you things about safety you won’t get from a managed language. It also teaches you about the hard stuff that developers like the Erlang core team have to take into account when designing languages that we use on a daily basis.


I already have web development knowledge, but I don’t have any experience of low level details, is understanding how memory work the most valuable skill to fill up first? (and after let’s go elixir)

Any language can enhance your knowledge.

For web development in particular, You could learn Web Assembly with Rust, or learn CSP with Elixir… they both bring something valuable.

Elixir is probably less popular than other web frameworks, but it brings something very new, that others cannot. It has OTP.

I would say learn both, and choose Rust for frontend, or Elixir for backend.

Elixir is functional, and Rust is OO or Functional, both use similar structs.

Going through the functional path will teach You a lot.

1 Like

Rust for frontend? Umm not sure that’s the recommendation most would make.


Rust for WASM…

1 Like

WASM, last I checked, could not interface with the Dom, which Imo makes it a poor choice for web UI. You’d probably need to use something like qt instead. Which might make for an interesting learning journey but won’t be easy to make web frontends with. I’d instead recommend building something that actually needs to manage memory manually, maybe a game or reimplementing a library or cli tool.

1 Like

I am overwhelmed with learning 2 languages.
I would like to focus on one language for a long time.

That makes a lot of sense.

Dear Friend, let me answer you with two short links that show that knowing rust is already very connected to the Elixir !! (When Elixir's performance becomes Rust-y - Kabisa) (Writing Rust NIFs for Elixir With Rustler | Blog | simplabs)

1 Like

Standard career advice for the start of your career - go wide instead of deep. Early specialization might be good, but it also has a tendency to be career limiting.

One of my good friends spent 10 years writing filesystems and various drivers for controllers. He became an architect, but still was massively underpaid. In fact, no one could understand how what he did would translate into anything else when he was interviewing. He had to leave the company and field to get paid. Eventually, he got a job at a startup learning web development and he had to go thru the learning gamut himself. Luckily, it was super-easy, cause when you’re working on filesystems, you have do everything yourself. Now he was working with python and he just had to break his habit of writing really good low level code instead of using some library. In fact, learning the vocabulary and words that people use was probably the most difficult part for him. After two years of learning the basics, he is now working at FAANG on low-level database design I think. Something low-level at least.

Now I’m not saying that you should never specialize eventually, but for right now, my suspicion is that you don’t even know what you like/dislike yet. Whenever a junior engineer would join my teams, I would have them do a tour of activities with small projects. These activities would ensure that they understand a few things for backend systems:

  • the importance of data structures. You can use whatever language you want, but if your data structures suck, the damn thing is going to fall over anyway.
  • database schemas - the next level up from data structures. They wouldn’t be ready to design tables and put them into production, but understanding the nefariousness of benchmarking and getting their head around sql is the key requirement here. If they can explain the tradeoffs the current team made, even better.
  • metrics, monitoring, and general observability - when they made a service can they prove it’s any good? The most important part is the tail latencies and performance on mobile or international customers. Maybe they’d even have to do some caching and understand how terribly difficult it is to do well.
  • pair on some low-level debugging problem which comes up
  • deployment - if there was some improvement to be made, this was always a good learning opportunity (blue / green, handling secrets, etc)
  • security - I’d have them go through recent audits from the security team and fix things.
  • qa - they have to show they can write an “appropriate” number of tests. No, I’m not a big fan of unit testing.

Other rotations could potentially include analytics, scheduling, sharding, databases, authentication, ui design, chaos testing, or any useful idea. They would need to be able to show that have some decision making ability and that comes from seeing different situations and the tradeoffs. For the ones that were interested in reliability, I would also give them time to learn elixir, which is also great for prototyping and system design.

But the basics come first because we live in a world where you need to be able to build stuff. All this work had a ton of impact at the companies I was involved with. Almost none of it has anything to do with systems programming.

So, in my experience, I can hardly recommend a systems programming language as an early choice. My language recommendations for new engineers is now:

  1. python - you can use it in almost any field - data, web, scripting, etc. You already know Kotlin, I’m assuming it is roughly equivalent as a generalist language. Python is easy though, you can pick it up when you want.
  2. elixir - for prototyping and system design, this is unbeatable. You can model an entire system in one application without having to have 25 webservices and kubernetes. If people truly understood the modeling power…I’m not going to start waxing about erlang/elixir. Once you get familiar with this ecosystem, the prototypes you come up with might be better than the production applications that teams spend 9 months futzing around trying to do fancy things because you can just do less and do it better. You might not be able to use it in your day-to-day job, but you have a long road ahead and there’s no better ecosystem to learn to to understand systems and just building random stuff. The core team is making it a more generally applicable language now, too.
  3. css - I just learnt css two years ago (lisp was previously at this spot). I spent 20 years building different types of backend systems. Building a good UX is much harder than building a decent backend, but if you want to build stuff, this has to up there. I regret not learning it sooner because that was one of my biggest gaps.
  4. a systems language - could be highly impactful for some subsystems. Early in my career, I wrote C, so I had this early. Rust was on my list of languages to learn, but now I’ve replaced that with Zig (I haven’t learnt Zig yet, but I’m donating to them. Really like the design philosophy.)
  5. a lisp - I had a team that wrote clojure for a year or two and so I picked it up. A lisp in general should deepen your understanding of designing around data.

My philosophy is to maximize the ability to build things. This isn’t to say become a full-stack engineer, but to understand what is happening at all levels of the stack. Become a B or a C player at most of these things and then figure out where you want to be an A-player. And learning how to build things well is about doing a variety of projects. It really isn’t about the language itself, but understanding different architectural tradeoffs and making sure you have the right tools to execute.

Also, get yourself a mentor who can spend an hour with you every week or two. And make sure they aren’t an idiot.

Edit - I can’t believe I responded to something where the original post was from Oct '20. Ah, well, will check the date next time.


Edit - I can’t believe I responded to something where the original post was from Oct '20. Ah, well, will check the date next time.

i’m happy you reopen this discussion with this so useful response ^^


Ah, glad you came back to look at it.

I just realized I forgot something rather important. I put data structures and database schemas at the top for backend systems, but I failed to mention SQL as a language. If you’re going to be working on any data systems, you’ll need to know at least up to joins, subqueries, and/or CTE’s.

I’d put SQL even before Elixir because it’s generally applicable. Anyway, good luck…

1 Like