Welcome to the forum!

If you already know JS and C# then I don’t think Elixir would be a challenge in terms of complexity. What can trip you up however is the functional programming paradigm – you have to learn that things are immutable and that the scopes of modifying things work differently e.g. you CANNOT do this:

a = 1

if something do
  a = 2
end

This doesn’t work. a only preserves the 2 value inside the if block.

So you have no mutation.

You instead do it like this:

a =
  if something do
    2
  else
    1
  end

Elixir is really easy to get into if you already have programming experience. For reasons unknown to me most newcomers skip the official tutorial, however I found it absolutely invaluable.

If you like what you see by the end of it, then move on to the Exercism.IO Elixir track which will truly open your eyes about what Elixir is about (especially the part where you will have to reinvent the crucially important Enum module).

If by the end of that, or even the middle, you still like what you see, the rest is relatively easily – there have been more and more employers looking for Elixir devs, some offering very chill and nice-to-work-at atmosphere. Be warned: the employer pool is much smaller compared to the vast ocean of JS and C# employers but then again, they (together with Java and a few others) are impossible to beat so not sure that’s an apt comparison. I however had almost no problems finding Elixir employment for 6 years now (although I have to admit most Elixir companies that I communicated with were super lazy in their hiring efforts during the summer!).

If you are more conservative in terms of preferring bigger employer pools then I’d advise you to aim at Golang.

I believe most programmers who worked with imperative / OOP / mutable programming languages do enjoy FP languages quite a lot because you forever stop playing 99.9% of all whack-a-mole games in your work (“who might have modified this global state again?” – a source of nightmares from all my 16 years of 7 other languages before picking Elixir).

The BEAM VM (the Erlang runtime Elixir steps on) is one of the secret weapons that somehow not many people still know about. It has solved 95% of the concurrency and parallelism problems just by the mere fact of having actors / processes / green threads that exchange messages and can’t modify each other’s state. And APIs like Task.async_stream allow you to transparently parallelize work, no matter how many items does your task queue have (so if you have 20 CPU cores then you’ll process 20 tasks at a time without lifting a finger).

Finally, every language has problems. An interesting side effect of Elixir’s rising popularity – and the rising level of seniority of the people attracted to it – is that a sub-group of its users (myself included) started being unhappy that Elixir doesn’t have static (compile-type) strong typing a la what Golang / Rust / Haskell / OCaml have.

OPINION: this has become a thorn in my side because it requires you to think about certain problems long before they might happen, and you become quite paranoid and sometimes even insecure. Whereas when I code in Rust I just make a sum / enum type for practically everything where I want to limit the space of the values and make errors of the type “unexpected function argument” impossible. But again, this is an opinion! Static typing has unquestionable benefits (prevent whole classes of bugs by the mere virtue of the program compiling) but dynamic typing has a huge boon as well: speed of iterating in your code. In Rust I have to plan out a bunch of things in my head and only after I code 100% of them can I test and see if my idea works whereas in Elixir 95% of the time checking your idea is just 3 minutes of coding inside iex (the REPL).

I hope the comments here help you make a decision. Even if you don’t end up working professionally with Elixir I believe just learning and practicing it every now and then will make you a better programmer.

There is opportunity everywhere. I think moving to Elixir or not is pretty independent of the overall landscape. What kind of problems do you want to solve? If Elixir sounds like a good fit for those then find a team to work in Elixir with because you’re clearly motivated to learn it.

Who I work with > compensation > problems interested in > language tooling

Is how I tend to look at career trajectory. It’s not too late to learn Elixir, I think it’s pretty easy to get far with it really fast. Frameworks like phoenix require a whole lot more specialization but I write very little real phoenix code compared to everything else.

Hope this helps!

Welcome to the forum, lokolan.

I think it is generally difficult to provide any general good advise for something like this, as it really depends very much on which kind of person and developer you are. But I can share part of my story:

Personally, I find it rewarding to try to work with new languages once in a while.
I have changed from professionally using C++ to Java, to C++ again, and I have been working for ~5 years full time with Elixir. Even if I were to go back to work with an object oriented language, I have learned a lot by spending time with a functional language. Of course I would have some catching up to do, before I would be fluent in modern C++ or Java, but I believe it can be done (and still make me a better developer in the end).

I totally agree with k3n, that the programming language is only part of the equation when it comes to career and job satisfaction.
No programming language will ever be perfect. Nor will using a specific programming language replace the need for being a skilled developer. This also goes for Elixir. Some of the code I wrote 5 years ago, which is still in production, is truly a mess and very complicated to understand. Other parts are easy and straightforward.

Like all other languages, there are many ways of structuring and writing Elixir programs. And as your system grows, certain ways of doing things are less optimal than others. Unfortunately, it is not always possible to tell, before you run into to trouble.
This is, as far as I see, just how software development works. There is simply no magic solution that can be applied equally in all cases.

What Elixir brings to the table, is an extensible language, an awesome foundation in terms of the BEAM, a set of really good frameworks and libraries (Phoenix, Ecto, Nerves, Plug, LiveView, Broadway, …) and an awesome community that generally has a very high quality of libraries.

I jumped head first into Elixir 5 years ago, and even though I have had my ups and downs with it (and there are things I dislike in the language), I am generally happy about that choice, and see myself working with it in many years to come.

I want something more standard, that everybody know to use and stop to renovate the circle.

We have this same problem in our project for having too much style of writing code in our code base from naming to pattern and etc.
But the problem is actually not from the junior or any project newcomer but from more of the experienced or other outsource people that we can’t control or communicate easily (we are also like one of the outsource in the project too)
The reasons why we have no problem within our team are that most people when writing code will try to follow or copy the old one. If your code is consistent enough or you can tell which one is the good example they will follow. So the problem lies in those who we can’t communicate with or one that already have followed another standard from somewhere else.

My point is coding standard is the person relate thing that you should build from your team using communication, language may help in some part but if you can’t control it, it will still happen somewhere.

And yes you should learn Elixir and also other languages. Learn the idea behind it, what problem is it good at, why people like this kind of idea from it. Even you may not have chance to use the language itself in job you can still adapt something from what you got.

It’s certainly a breath of fresh of air coming from the JavaScript ecosystem after a serious burnout.

Although I could be considered a Sr. Fullstack developer under JS, with Elixir I have barely scratched the surface.

What I Iike the most is how easy is to maintain and add features to my own products.

The leap to production requires less tooling than a Node/React project with similar scale.

I can build, not just MVPs, but production quality products almost on my own. With less effort and people than with other languages/frameworks.

I can focus just on building, not worrying about shinny toys and FOMO.