Have you moved away from elixir? If so, why?

In the current context, Croatia, it is difficult to introduce the language. Since there are default language/tools preferred in the region (it can be argued in general), I’m heavily investing time in Rust, even though it’s contradictory, and even more extreme to introduce that ecosystem. Current reasoning is that it is true general purpose language with a lot going for it. Still checking out this forum, because of the great pool of people and culture.

I wasn’t even able to introduce it at work. Most german companies just hopped on the NodeJS hypetrain and they are too stubborn to move away from it for quite a time I guess.

But I use Elixir for all my private stuff and don’t plan to move away from it.

I might have a soft talk about strategies for introducing Elixir to a company. You need to find a low-risk project and create a service that need little attention, just do what it is supposed to. At some point they will notice that this node has just been running for years without much maintenance.

The realisation that developers often talk about their passion and managers often talk in dollars/euro is a good one. It is a hard sell that the initial setup might be costly, but that it will pay itself back over time—it really is something they need to see and experience.

So the best way is to introduce it as a microservice, and eventually they will realise the value and want it in more places.

My home country, Denmark, is mostly run by Microsoft—so I feel your pain.

Our current customer wants to create a background worker for doing time intensive tasks. I said that it would be a good fit for Elixir but now they seem to do it in Golang. I guess they just rely on docker to restart the worker if Golang decides to randomly crash because of some faulty or outdated input.

Had the same argument at a previous employer. What did I end up doing instead? I quit and now I’m studying full time at uni which allows me to play around with the OTP as much as I want. I also plan on doing my masters in the field of distributed systems and hopefully land a job which allows me to build these incredible systems.

I did “funemployment” as well a couple of years back when my employer at the time was determined to keep using nodejs. After half a year of just waking up in the morning, reading about functional programming and coding Elixir, I got picked up by a start up (which didn’t fare too well) and eventually I got an Erlang job at a successful company.

It is a risky strategy, and I am not sure I will recommend it to everybody

Still using Elixir, not planning to drop it. But also learning Rust, because I need to write some reliable networking code that I can reuse across servers & mobile…

I could see myself becoming comfortable with Rust enough to use it for new projects instead of Elixir, maybe, not sure, time will tell. I don’t see ever being as productive in Rust as in Elixir, but I can see the possibility of it becoming close enough. Ask again in a year

IMHO the team should make the decision(s) about the language(s) they use, not the employer. Of course, there are constraints to take into consideration. But the employers usually have no idea about what matters in technical details. The employer probably will make their decision based on what they hear, or read, or guess what the neighbors will do. That’s why most companies still stuck in that weird Java-world.

But, really, if they pay you as a developer, they should listen to you, not to some insane industrial lobbies.

If your employer force you to use a specific language (without any comprehensible arguments) change your employer, not your language

If you have to argue about technical stuff with your boss or manager, don’t even try technical arguments. If you don’t have economical arguments, you’ll gonna lose!

By the same argument, if leadership has no intentions of cross-training their developers into operations, or of hiring developers who are already capable of such, or of hiring infrastructure folks who are capable of supporting whatever esoteric language a team wants to ship with, they have a very strong economic argument to stick with the “well-paved roads” that don’t require any specialized infrastructure knowledge. If deployment considerations aren’t planned for up front when deciding a tech stack, it’s way too late to change course by the time it becomes a pressing concern. (Assuming you’re not standing up your early prototypes on real infrastructure as soon as possible, which IMO is healthy but can be a drag on perceived velocity.)