> Providing a stable currency is legit

The US does not "provide" a stable currency, it outright forces everyone to use it.

> how enforcing your ideals often comes into conflict with the values of your ideals themselves

The US/NATO couldn't care less about enforcing their "ideals". This is all about economic gain. It is very odd how liberal ideals must be enforced upon Iran, but not upon Saudi Arabia, which is a US ally, no?

> but that is another conversation, not for this thread

So discussing the use of force in the global economy is not fit for a thread about free-trade?

> If you don't intend to discuss out of position of curiosity

I'm not the one making sweeping statements on the superiority of one piece of technology. Reading your other response, I think you are the one who have little to no curiosity in understanding how you might be wrong.

Amazing how it doesn't even cross your mind that there are trade-offs to those choices. Green threads are awesome, but guess what, they come at a cost. Same for share-nothing semantics.

> Has anybody rolled up their sleeves and said "Alright, BEAM VM's reign is over, I am making the same or better runtime as them in Java / Clojure!"?

You are again presupposing the BEAM has an absolute superiority over the JVM. "Better runtime" makes no sense on its own. Better is always relative to something. Better for whom? For what?

I'd bet that you work on a traditional CRUD enterprise software, and that IO(the database) is the real bottleneck of your app. In that case, sure, the BEAM is a solid choice(so is Python, Ruby and PHP nowadays). But let's please not pretend that is all there is to software engineering.

> I am not denying that the JVM might have almost caught up in the meantime. More than a decade ago it did not.

This presupposes that the JVM had something to catch up in the meantime. Again, this lacks nuance and brings nothing to the table. The JVM makes different trade-offs than the Erlang/Golang VM does, and has different strengths and weaknesses. Both of your comments completely ignores that.

> It's just that in my work I have found having to avoid them still worth it compared to the alternatives (global mutability and more primitive parallelism which was the case for the JVM for decades).

Clojure runs on the JVM and avoids mutability pretty well. It is amazing for writing concurrent software, and has been for many years(i.e more than a decade ago).

> Similar to the weird childish name-calling people do in Rust threads

I've seen people do similar things to the JVM.

Still, funny how you ignored IRCs/forums that I mentioned. Those were used by MANY people, and could scale infinitely. You are literally arguing against something that has already happened.

I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages.

There is research out there, and there is absolutely zero evidence that static typing catches more bugs than dynamic types. My experience is that immutability, functional programming, simplicity and testing pays a MUCH bigger role in maintainability than static typing.

Dynamic typing has trade-offs, and so does static typing, HUGE trade-offs by the way. But for some reason, no one seems to mention them... ever.

Why?