Andreas Kling aka @awesomekling wrote:
We've been evaluating a number of C++ successor languages for @ladybirdbrowser , and the one best suited to our needs appears to be @SwiftLang 🪶
Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!
Why do we like Swift?
First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.
Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.
The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
Strong ties to Apple?
Swift has historically been strongly tied to Apple and their platforms, but in the last year, there's been a push for "swiftlang" to become more independent. (It's now in a separate GitHub org, no longer in "apple", for example).
Support for non-Apple platforms is also improving, as is the support for other, LSP-based development environments.
What happens next?
We aren't able to start using it just yet, as the current release of Swift ships with a version of Clang that's too old to grok our existing C++ codebase. But when Swift 6 comes out of beta this fall, we will begin using it!
No language is perfect, and there are a lot of things here that we don't know yet. I'm not aware of anyone doing browser engine stuff in Swift before, so we'll probably end up with feedback for the Swift team as well.
I'm super excited about this! We must steer Ladybird towards memory safety, and the first step is selecting a successor language that we can begin adopting very soon. 🤓🐞
Well, I'm off to a great start! Ha ha... This is why I ask. I assumed you'd bring up at least two, but if I couldn't even get that right, then I clearly wasn't reading your comment in the intended spirit. I was confident there was more to it.
For what it's worth, I completely agree with you on the following, (sadly) down to the Teams mention:
The only thing I'm unsure about is this:
I believe it strongly depends on which views we're talking about. The problem is that while certain disagreements can be harmlessly put aside, and you may even work together with these people, at some point you'll find views that are harmful themselves. Maybe they don't hurt you directly, but they can hurt others.
Using software and engaging in communities of developers with harmful views means platforming those views, even when you disagree. You're telling developers, "It's fine to hurt others if you're good at writing software." You're telling people it's okay for them to hurt others too, because if respected devs are allowed to, then why shouldn't they?
For a rather extreme example, Hyprland's project lead is on record saying he could be swayed on genocide. Mind you, this is not the only issue with the project. Vaxry has been banned from the freedesktop mailing list, because they're not interested in platforming toxicity. Many have ditched Hyprland (and Vaxry) altogether, even though it's an impressive project in terms of technical achievements.
I'm not blaming unaware users, it happens! The problem is when you become aware of an issue, and you don't speak out, don't take any action, don't support the ones being hurt. I'm not trying to order anyone to do all of those, but too many don't do a single one and are seemingly against others putting in the work.
Look at the downvotes on my top comment: why should an attempt at informing people have its visibility lowered? They were not as kind as you to reply. Not claiming you downvoted me—nor would I mind if you did—but a -1 is hardly useful feedback to me, is it?
If I had known the full extent of Lemmy devs' views from the start, I'm not sure I'd have joined. For most projects, once you're in, it's harder to leave than it would've been to avoid. The cost of switching isn't a shackle, but is certainly a deterrent. This is why I try to be careful about which projects I allow myself to support.
Point being, some views are absolutely solely determining factors in me not using the software.
And again, Lemmy and Ladybird aren't comparable in this discussion due to the fundamentally different nature of the projects and the ways in which people interact with them. I'm willing to elaborate on this, if anyone actually wants that, but this comment is long enough already.