I realize I'm about to post something that sounds like the most generic HN slop comments... but, considering it's why Mozilla initially made a whole new language in the first place, I hope most can look past what fanatics would normally say and focus on the scenario:
I was ecstatic about Ladybird from a "fun NIH project" perspective but once it became "serious" and had a cross-platform daily-driver long term focus it was quite the let down that the hot new independent kickstart was... still going to be built on C++ anyways. Even the Serenity ecosystem had started work on a NIH memory safe language - Jakt! I'm not going to say the "R" word (mostly because I'm less interested "which" and more interested in the "what") but the one place I'd really like to see memory safety is the new fresh-engined web browser written by a small team (or really, any team).
On that front https://servo.org/ is "alive" again under the Linux Foundation. It has a focus on being an easily embeddable engine and it seems to be picking up a bit of steam. Whether or not it really takes off remains to be seen. I'll be watching closely though!
I think Ladybird is being developed in swift, it just has a lot of c++ code that they plan on replacing because it started as a fork.
I agree with you there, on all parts.
My reason for learning Rust in the first place was trying to contribute to the servo engine. But then, Mozilla happened. My hope for servo continues, but it won't go anywhere if it stays in the limbo it has been in after Mozilla ditched it as a project. We need a real browser project, with a full UI/UX and everything, until people take it serious as a base to fork off.
The problem with reality is that almost all software is still built on C. Kernels, userspace APIs, libraries, everything. I just wish that we would've gotten something like C ABIs, but with memory safety and VM-to-VM communication in mind, e.g. for Rust and Go, along the way. WebASM / WASI somehow got there, at least in that direction. But it's never seen as a shared object or dll replacement, and always is just a compile target and nothing more - even when the potential is there.
Something like that would solve so many problems that all kinds of programming language are trying to solve by themselves, over and over again.