I'm sure they'll have some success. But if I was the engineering manager or technical lead for teams like this, I would be cautious. From a hiring/staffing poin

I'm sure they'll have some success. But if I was the engineering manager or technical lead for teams like this, I would be cautious. From a hiring/staffing point of view it is foolish and probably unnecessary; there is a large pool of talent trained in existing web framework tech, and generally most web applications do not need the latency guarantees that come with a non-GC language like Rust. If you're trying to staff and maintain a team doing this kind of thing, picking boring old TypeScript and staffing up with excellent senior engineers and just applying rigorous quality controls and engineering standards to the codebase makes more sense. It gives you better ability to bring on new staff, and to use existing frameworks. FWIW I worked in ad serving for some years (at Google and prior) and much of that work is done in C++ because of millisecond granularity P99, etc. latency concerns. Rust is a natural fit there, even though that is nominally "web serving"; but that's a different domain than serving up database-backed microservices for typical web customer workloads; that stuff is on the whole I/O blocked and not impacted by GC sweeps.