I highly recommend playing with Elixir or another purely functional language. I've only gone through the Programming Elixir book[1], but it has fundamentally challenged how I think about solving problems in other languages.
Not for me. I've gone back and forth between projects that required functional languages, and projects that didn't across different companies. Bad code is bad code no matter what language it's written in. What makes me love my day job is whether I have the ability to make it better, and if those that work with me are aligned in wanting to do so.
I think practitioners of functional languages get a little preachy when really, exposure to functional languages should just be assumed to be part of the basic training of any engineer. It's a tool and as good as it is for some things, it's absolutely awful for others.
Low level code. Drivers, interfacing on COM/serial/USB ports, graphics programming or anything that requires more finely tuned data structures you have to manage yourself, low latency work where you can't afford to have a random GC happen at a bad point in the run loop...
But then you'd be ready to start on a new day job with tools and concepts you really enjoy using ;-)
It's not just a matter of syntax and such but a whole new way of thinking - specifically immutability, functional aspect, using lightweight processes, hot code loading, sane handling of crashes and restart, easy tracing, etc. allow approaching and solving problem in whole new ways that is often a lot more efficient (both performance wise but also operations-wise).
Even if you switch to using other language you'd find yourself trying to apply some of these techniques so it is a useful set of things to learn about.
I got lucky and found an Erlang one. In general there are a lot less of those than other jobs. It's kind of a double-edged sword, there are lot of Java / JS / Python / C++ jobs but there are also a lot of programmers who apply for those.
If I had found an Elixir job I would have taken that as well, most of the harder to grok concepts are pretty much the same between the languages. And I do prefer Erlang I find it simpler so far.
If you are interested in learning a purely functional language, I'd recommend against picking a dynamically typed language like Elixir.
Functional programming only starts to show its power with types and parametric polymorphism (higher kinds, etc...). Without type annotations, all you get is a watered down, crippled version of what a functional language can achieve.
Well first, Elixir isn't purely functional. It's got side effects all over the place, it just doesn't have mutable variables.
Second... While I love static typing as much as the next guy, there's definitely value in immutable data in a dynamic language. You also get Dialyzer in Elixir/Erlang, which is an interesting alternative to the usual type systems you find in Haskell/Rust/etc. in that it focusses on finding places where there's provably a problem, rather than where it's not provably correct.
> there's definitely value in immutable data in a dynamic language.
Sure, but there's even more value in immutable data in a statically typed language, because of all the advantages that come with such a language (automated refactoring, better performances, tooling, etc...).
I've been working with the BEAM (via Erlang) for over a decade, and with Elixir for almost 1.5 years, and I'd still give up, well, probably my current job if I could get a fully Hindley-Milner Typed Elixir...
Yes, mis-typed when I typed purely functional. My intent was to lean closer towards mostly-functional languages than languages which _can_ be written in a functional style (a la JS or Ruby).
I should know better than to use the word "pure" on the internet, someone will always correct how inaccurate my usage is :)
Functional languages are perfectly capable languages so you can typically use them for anything you'd use any other language for. But if you want a project that specifically showcases functional programming, writing a parser using parser combinators can be fun and instructive.
I don't like to think of a lot of these languages in terms of "functional". Haskell specifically does follow a functional paradigm, but Erlang/Elixir is more about the actor model and the functional aspects support that.
This book is for 1.3, and Elixir 1.5 just came out. Just a heads up, the author is currently working on "Programming Elixir 1.4". Believe it's coming out in November.
[1](https://pragprog.com/book/elixir13/programming-elixir-1-3)