likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often
(BTW, when I wrote "Not one of those projects ... changed their language", I meant after less than a decade, as a continuation to the previous comment)
First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).
Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.
First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).
Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.