>It's just that software engineers like to pretend they're fully rational beings

So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit.

IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.

> Is there any actual evidence that one stack is better than another? No, not really.

It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file.

Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.

I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit.

That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)

there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.

I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small.

You could always target scala/akka engineers with it. Theres a lot of crossover there.

there are definite differences but in most cases we do not have the ability to make an actual rational choice (verging between a lack of hard numbers and an inability to predict the future).

so in fine it's touchy-feely.

Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making.

It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development.

This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.

I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.

> building bridges or constructing dams.

Discuss your ideas with a civil engineer

You'd be surprised how similar our professions are

Our shoddy work is our fault, we know how to do better, we don't

We are like civil engineering in 1850

I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.

Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector).

> types and runtime type validation

This is what "dynamic typing" means.

In other languages, you know that the types are right /before/ you run the code.

Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.

I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.

The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain

> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc.

It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).

TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet.

Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.

> Running an on-premise cluster [...]

You don't need a cluster for most things. A simple server managed with Ansible playbooks will take you quite far.

It's quite telling that running on a regular server isn't in the list.

Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”.

Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.

u forgot TCL, i write web apps in TCL and Apache/Rivet :)

There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.