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
This doesn’t work.
a only preserves the
2 value inside the
So you have no mutation.
You instead do it like this:
if something do
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
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.