Opinions about investing on Elixir being Senior in other language

Hello. I’ve been having some trouble to choose a better decision in my career.
I’ve been working Senior NodeJS backend for the last 6 years and I already work a lot with C# too.
Today I’m a little bit frustrated about so many frameworks and a lot of packages that we need to in Node. I always feel that I never know enough about what I should use and what I’m working. Other thing that have been annoying to me is always being designated to work on Frontend just because I know javascript.
I’ve been considering to change to Elixir for work totally focused on Backend, either monolith or microservice.
I just want create scalable, resilient and concurrent APIs. Leave this world of Oriented Objects and investing on Funcional way.

My great doubt is would be better if I change to Elixir to focus more on backend or continue focusing on Node because it’s too late to change language and be specialist on Elixir?
I already built some API using Elixir, and I can consider take a Mid level job on Elixir, but I’m afraid of have some trouble to find these opportunities and some company give me the opportunity to migrate of language, I’m afraid of switch language is learning curve be big and opportunities to work Elixir only in backend be scarce.
Maybe it would be shooting myself in the foot?

5 Likes

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!

6 Likes

Thanks your reply.
Today I want to have a solid way to create a good backend, not hard to understand and in general one way to code. I hate when someone create complex code just to show knowledge in the language, It’s difficulty to explain to junior dev what it’s happening in legacy projects sometimes. I feel that Elixir seems like one way to write, not like others languages that you have a lot of options to do the same thing you know?
I would like to have an way to build an API or Workers with a good documented input and output schemas, detailed responses, maybe autogenerated swagger? have a easy way to scale and concurrent programming.
I feel that because of modularity of Node, it’s hard to take a very well documented API. People just use what it’s easy to config and avoid to improve some details.
I want something more standard, that everybody know to use and stop to renovate the circle.

1 Like

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.

4 Likes

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.

4 Likes

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.

8 Likes

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.

3 Likes

Thanks everybody. I really appreciate your kindness.
I will continue improving my JS skills and will learn more about Elixir. I did a course in Udemy and really liked the language.
Thank you @dimitarvp I’m sure that I gonna check Elixir track. I want improve more Elixir skills before jump to Phoenix.
Even If I not able to work Elixir, I gonna study. Maybe one day in some project we need to use and I gonna be prepared.
See you there!

2 Likes