“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.
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.
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.
> 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.
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.
> 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.
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.
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.
yeah, it was way better when you worked the fields for a duke who had dibs over your underage wife for the first night of marriage. and don't forget the round robin slave labour in the castle! and don't forget to set aside some grain for the taxes, who cares if this year has been bad and it all goes to the duke...
capitalism has its faults, but these platitudes about rotten systems really miss the mark.
I could get behind your general sentiment perhaps in the context of 19th century industrialism, or maybe even 20th century robber barons, but what paradise for the masses does the 21st century of “billionaires with no nation-state allegiance” bring exactly?
Also, concentration of wealth doesn’t reverse without action - so your initial remarks on fiefdoms and feudalism may not be too far from where we find ourselves in this century, which king do you bend the knee to: House of the dragon, Zuckerberg, or House of the camel, Musk?
I agree with your sentiment - I simply don't have a specific answer or I would be a very important person as I would have "solved" one of this century hardest problem.
I just believe that technology and innovation and creative destruction (in the schumpeterian sense) can (as they did) bring better resource usage which in turn drive better lifestyle for everyone.
I'm not sure where I would go from here; my brain is wired to my country problems (which is not usa, I hail from europe) which are completely 0 opportunities to actually get rich + complete domination of old money due to compound interest unstoppable force.
Heavily taxing inheritance in every form could be a start, but I'm not an expert in policy.
I mean, I suppose we're not chattel slaves or sending our kids into mines.
I mean, someone is, because that is the only way to get billionaires.
But it's not us or our kids, at least.
HN is great for getting a little window into how the rich sociopaths in this culture live.
When folks write ahistorical fantasy, as you've done here, it's a very useful picture to help understand what kinds of really bad things folks are capable of thinking about the world.
the only thing this llm craze is helping is nvidia/openai/ms war chest, and fueling the illusion that every company can finally have their developers by taking any domain expert or barely knowledgeable person paired with an ai assistant. the mountains of trash produced by these things will end up costing a metric ton.
let's also measure the productivity of reviewers and people in general that, at a later point, have to wade through piles of ai generated crap.
last friday i had to review 2 trash PRs that were blatantly made with ai coding assistance. hundreds of code lines for something that, by reading the doc of the library, could have been made in 5 lines. and the fantastic comments like "returns the body" over a body() function.
