The most popular distributions are rolling-release ones, so not sure about that.

> 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.

> 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.

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 am not sure why someone would downvote this. It is 100% revolting and indicative of a really rotten system that allows this to happen.

I think it's too early to tell but my main concern about copilot is code maintainability and security. Copilot is able to barf out helpful expressions that will reduce the amount of code we need to write by hand - I think it's excellent when it comes to reducing boilerplate... but I think a large amount of boilerplate existing belies a bigger issue with the project. The majority of software engineering isn't writing code - copilot may be beneficial as an accessibility aide for developers that have typing impairments but most developers can type faster than they can think - if the level of boilerplate in your project is reasonable then this should mean you're never prevented from thinking because your fingers are still working on recording your previous thought. However, at the end of the day, if you can help reduce carpal tunnel that's still a win.

The problem I can foresee with copilot is that the scenario change you're agreeing to is that you'll type less but need to read over the code produced more - this is an effort that isn't normally necessary (typos happen but those should take a trivial time to correct) but when copilot is involved you need to proof all the code that is being generated. There is a motivation to skip this step and just accept the code was written correctly and that will inevitably lead to security problems - and there is a motivation to not correct or alter auto-filled command. If there's a multi-dimensional array and you think it semantically makes sense to iterate it over dimension a then dimension b and copilot instead goes with b as the major index then it's more likely to remain in a b major iteration - that may make code less readable or it may cause major issues down the line.

Copilot, IMO, is optimizing the least important part of development right now and it costs us more to correct it then it would to just splat out the correct code _but_ this is a similar argument to longbows vs. crossbows - hand a peasant a crossbow and they can fire a crossbow - train a peasant for 30 years and they can fire a longbow - the longbow is more powerful, but the crossbow is a clear choice in terms of RoI. It may be that today's developers will only benefit from copilot minimally since we've invested the training time in standard development practices but tomorrow's developers will eschew a lot of the algorithmic learning and still be able to deliver the majority of the value.