[gv83]

“Why not Elixir” is a more interesting question and I suggest you go ask it to engineering managers of polyglot organizations. They will usually bring you the super low nps from not-elixir-only devs and the resignation letters from elixir “talents” that are asked to do non elixir stuff.

[doawoo]

Funny, this happened to me specifically.

We were an all Elixir (and legacy Ruby) shop with some wildly smart engineers.

Got acquired and jammed into another larger org. Got pressured to switch to Java and Go without considering that maybe our system was designed around the way OTP apps work.

Fast forward a few years and lots of us left, and found successful Elixir jobs where we were much happier elsewhere, making much more interesting technology.

Sounds more like an org problem to me.

[nesarkvechnep]

Is this a problem with Elixir? Have you seen a Java dev using a different technology? They usually haven't even heard of anything besides Java.

[mekoka]

You've successfully been dealing with a sand problem with shovels. Then the new boss tells you about these amazing forks that they've used in the past to address any and all issues and wants you to start using them too.

Quitting is not you being difficult. It's just opting out of a bad developer experience. Contrary to popular belief, you're entitled to also be happy as a professional programmer.

[neonsunset]

Which is why I would quit if someone tried to pry high throughput .NET-based microservices from my hands to replace them with something like Elixir.

(A similar story has happened at Walmart when their architects did not understand F# and instituted a Java rewrite of an acquired company)

[toast0]

> super low nps

Net Promoter Score?

> resignation letters from elixir “talents” that are asked to do non elixir stuff.

I mean, I would prefer to be working in Erlang, but I took a Rusty job recently. OTOH, if I was working in Erlang for you, and you made me switch to something else, I would most likely not be happy and if my job is changing, I may as well change jobs, or at least consider it. Leaving behind simple concurrency and hot loading means it takes a lot longer for me to get things done, and it's one thing to work at a job where things take forever, but it's even worse to go from being able to get things done quickly to slowly.

[gv83]

yes, Net Promoter Score

about the second part of your answer; my (probably very rare) opinion is that our job is not to "work in erlang" or "work in rust", is "solve problems/automate stuff". If I ask you to work in Foo instead of Erlang, it's the same job. I highly doubt that your job is slow because Go and fast because Rust, it's slow because process/idiots in other teams/idiots in your team/idiots as your "agile coach" etc.

I understand wanting to have a good career, but language is never the obstacle to a successful career. Also, this implicit bias that people who know exotic languages are better is completely false.

[toast0]

> I highly doubt that your job is slow because Go and fast because Rust, it's slow because process/idiots in other teams/idiots in your team/idiots as your "agile coach" etc.

Team dynamics are of course, very important. But my job is slow absolutely because I don't have hot loading. Sure, yes, I could build hotloading in Rust, but it would be difficult and the resulting code would look be a lot less idiomatic than my Rust code is already; which makes it harder to do.

Because I don't have hotloading and I work with a system where long lived tasks stay on a single server, I can't change the code for existing tasks in progress. Instead, I have to set up a new cluster and let new tasks start on the new cluster, and then I have to later come in and cleanup the old cluster. This is a lot more work than pushing and loading new code on the existing cluster. And it means I need to wait longer to see the results. And tasks have a limited lifetime. Because of the operational cost of doing an update, it's not worthwhile to do small incremental updates, instead I have to batch things into substantial updates and keep track of more things.

At my previous job, we would regularly have tcp connected clients connected for weeks or months with the latest server code via hotloading. I can't do that now. Either I let clients stay connected to old code servers, or I force them to reconnect and lose their state. (Yeah, maybe there's a way to force them to reconnect and transfer their state; that's not easy though)

It's like making a mechanic work without powertools. Yes, you can do everything, but without the proper tools to do my job, everything takes longer. A mechanic trained without access to or knowledge of power tools might not notice the difference, of course. And power tools offer the ability to do both good work and bad work much faster.

Edit to add:

Re the job is to solve problems regardless of language; I don't necessarily disagree, and I'm definitely willing to pitch in and debug nearby systems that are outside of my preferred language, or even write code in a language I despise if it's the best way to solve a problem. But if the majority of my job is in languages that make it harder for me to work, and that's not something that was clear before I took the job, and especially if it's a new thing, it's going to make me look for something else. I'd expect that just as much for someone who feels Erlang makes them more productive as for someone who feels Rust or Java or C or Erlang or Fortran or Lisp or Python or whatever language they love. There's a lot to like about a lot of languages, even if they don't appeal to me.

[gv83]

hey, maybe you have one of the use cases erl/el excels at; I'm not going to go against that - I also like the language and the runtime and everything.

my point is just that at some point and at a certain org size, the technical prowess of the platform is not the dominant term in the equation; social merits of your platform become it.

organizations also don't see the value of retraining everyone, risking bugs, customer and dev dissatisfactions, and a myriad other correlated problems; and as elixir orgs are not running laps around non elixir orgs (you know, executives do talk with other executives in other companies - and whatsapp is an once in a decade) and given that most of us build web cruds, internal LoB apps, other small automations, they can tolerate the eventual delays of having worser tools.

closing our eyes and thinking these things do not exist is ingenuous imho; I wish I was writing rust or el, I'm stuck in python trying to convince people using immutable dataclasses.

I still feel langs like el/erl and in general pleasant, powerful but niche things like clojure, are better placed as secret weapons for teams of highly skilled, motivated individuals with homogeneous culture about code. They are not industry standard and they should not be. Touting them as magical solutions just hurts them in the long run.

[icedchai]

This often happens regardless of tech. The old school Unix guy that does everything in C... The C# person who hates Java... The Ruby guy that won't do Python... The backend developer that despises Javascript... on and on. Some people compromise, some don't.