For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.
Also, they’re not doing a massive rewrite:
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in a modern language sounds like a dream come true.
> For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.
Yes. But many terrible decisions are taken this same way.
> and I hope this decision pays off
It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointing to.
Guy doesn't even know Swift yet, wants to rewrite a Chrome/Firefox alternative using it. That's a great recipe for failure. Alright, I need to find another browser project to be delusional about.
I strongly disagree. This is not a justified decision, they just feel like it based either on vague and speculative reasons, or because they are funded to do so, I would not be surprised if they had discussions with the Swift marketing team.
Andreas has been talking about liking and exploring Swift since before he started working on Jakt [0] and if you look at Jakt you will clearly see it is heavily influenced by Swift.
I feel like the tweet explains their rationale pretty well... the main reason being memory safety. It's a constant overhead in both programming time and bug handling for them.
I am very confused by your message. I know both Rust and C++ and think it’s an improvement in many ways. Why do you you think it’s worse without using the language?
The original tweet was essentially complaining about boilerplate, which is all that's involved in managing most "complex object graphs" in Rust. If you think some minor boilerplate makes languages "extremely anti-ergonomic" I sure hope you're not writing Java.
> Work is still ongoing to make Servo consumable as a webview library, so for now, the only supported way to use Servo is via servoshell, our winit- and egui-based example browser.
A shame, really, since the Servo project was the source of some of the best macOS Cocoa/AppKit bindings for Rust.
Servo was never usable as a "real browser", and it's been revived since last year by Igalia. Looks like you should refresh your view on the project overall.
I had a 2018 (or 2017?) build on my Mac that was a native app using Cocoa/AppKit, which had a URL bar and could do most things in a functional capacity (like using Google services). AFAIK I tried a newer build back in 2020 or 2021 which had stripped out all of the browser chrome (like URL bar). Maybe they had intended to add it back in the future, but didn't get to do that before, you know, the layoff.
Servo the project was never revived as it was originally; the Servo name is being reused for what is actually a continuation of just the webrender project, which was part of the original Servo project, but is nonetheless much more limited in scope. I know it's confusing. Servo was once going to be a browser plus engine, and now it's just the engine.
Of course, officially, Servo has always only been a "research project" to "rethink the browser at every level of the technology stack", which primarily meant "layout engine", but then again, they did do such things as creating their own bindings to macOS Cocoa and AppKit which has no place in a layout engine, just to create, you know, a browser that demonstrates the engine. The browser that used the engine was part of the project.
Nowadays, the new Servo does have a demo/example project, but it's not meant for end use like the original Servo browser would have been. It just uses egui and all the other parts of the original Servo project have been essentially deprecated in favor of the new one, which is just webrender.
You are absolutely wrong about Servo being revived just a continuation of the webrender project. Igalia has been leading the effort for about 18 months now, focusing mostly on the layout engine (which is not webrender).
> who cares when a volunteer writes a browser in any language?
All the people that replied with something akin to "Why is this written in C++" when Ladybird was initially announced, which probably influenced the decistion to switch to Swift.
Also, they’re not doing a massive rewrite:
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in a modern language sounds like a dream come true.