This framing is misleading. I'm not sure what AI has to do with any of the examples you cited. All of the examples you cited are moves - and in some cases, not even moves, as Shopify is not ditching Ruby - to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language, and no link to AI that I can see, as these companies all significantly predate LLMs.
Ruby's runtime in the early 2000's compared poorly against the JVM or the BEAM. People used Ruby then and now because it worked well to get products to market quickly. Even after a ton of investment in Ruby's implementation, the JVM and the BEAM are still better able to handle the types of high-traffic, high-concurrency workloads those companies serve, which makes them relevant to mature, high-scale companies.
Tellingly, there are dynamic language implementations that are performance-competitive with static language implementations, like Javascript's V8/Bun/Deno, Lua's LuaJIT, and Common Lisp's SBCL (among others, this is not an exclusive list).
> to more performant runtimes and architectures in response to operational concerns at scale, which have a tenuous link to language
The runtime performance and the language are deeply linked. None of the dynamically typed runtimes you mention are actually performance competitive with JVM languages.
Luajit and SBCL are very much performance competitive with the JVM? Why do you say that they're not?
Random example benchmark: https://madnight.github.io/benchmarksgame/lisp.html
That's someone's 8 year old mirror of the benchmarks game website.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
These mean nothing. The C/C++ implementations use SIMD intrinsic while Lisp doesn't (it should have used sb-simd).
Huh. And after eight years, SBCL and Java are side by side, still.
They absolutely are. Maybe not if the only thing you’re benchmarking is something completely CPU bound like signal processing/math, but they’re definitely competitive for tons of real use cases.
They don’t really need to be though. They take far fewer tokens and are still faster to develop with