Ladybird adopts Rust, with help from AI
We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited.
Linux kernel, git, debian apt, maybe next is macOS kernel adopts Rust!
Come on Swift team, we need better performance, real cross-platform compiling capabilities, make Swift swiftly.
Ah, if only there was referential binding of associated values in switch over enum.
Or if @_implementationOnly import would be converted into a production ready feature.
This is what community should focus on, not pointless chasing of Swift for Android or Swift on Server.
So, in the abstract this isn't an unreasonable thing to discuss, but in reality I've never seen this kind of thread lead to anything useful. We can already see the reasons why: the Ladybird blog post doesn't explain their rationale in depth, but they do mention two things in specific, both of which were immediately forgotten in the commentary here. I'm just going to go ahead and close this.
Also, it's pretty rude to tell other people that it's pointless to work on the things that matter to them. In any non-trivial project, different people are going to have different priorities.
In retrospect, I think I was too hasty to close this thread. People ought to have the opportunity to have a thoughtful and introspective discussion about this here, and perhaps a gentle course correction will be sufficient to let that happen. If the thread wanders off into unrelated wishlists, I can always close it again.
I'm glad they didn't choose Swift, we already have too many "AI" evangelists. I was contemplating trying out Rust for my side projects but if you look up "rust conference" on YouTube, one of the top results is some "AI" bullshit from the Rust Foundation (and most results for this and similar searches are by "Don't recommend channel").
Most of the current Swift contributor experience looks like this:
At this points, I'm starting to question whether Swift is open-source or source-available.
I'm pretty sure internal import is the direct equivalent to @_implementationOnly import. But it's badly designed and you should be able to define public/internal dependencies in Package.swift/CMakeLists.txt/etc. instead.
It's good to be able to easily convert a high-skilled iOS/macOS developer's value to other platforms. Assuming proper compensation instead of hiring 10 more people with similar pay, so the high-skilled developer starts matching the others' productivity.
I also have 3 Swift-on-server projects that are running on my home server.
I was sad to see they didn’t continue with Swift, because it did feel like a big win (and as I was curious to see how they implemented certain features.)
However, it’s just one project. I’m doubling down on Swift becoming more powerful than ever before (nothing against Rust).
Things like ~Escapsable, Borrow, Inout , and lifetimes etc can fill the gaps.
At the cost of dealing with a borrow-checker all the time? No thanks, there are other avenues.
What are you missing now? We already ship cross-compilation bundles for linux and Wasm, with Android up next. The Swift SDK Generator lets you target a bunch more of your choosing.
Note that all of these can be used with a single Swift compiler, as unlike some other languages that require you to build a separate compiler for each cross-compilation target, the Swift compiler already supports cross-compiling to them all! Makes sense, as Swift since its initial releases has primarily been used for cross-compilation, from macOS to iOS.
I doubt I would be able to implement those compiler features anytime soon, but I can get a lot more done for Android. 
In other words, not only do Swift devs have different priorities, as John says, but different skills and knowledge: we are not fungible.
What is fungible is money, so if you find a dev who can implement those features you want, you could send that dev some money and sponsor them.
As for the Ladybird project, I don't think a new web browser is worthwhile, as the web stack is dying tech, just like previous cross-platform app runtimes like Flash or Silverlight died out. I do think we need some app runtime like that to keep platform vendors on their toes, but it will take new ideas to revive that.
I know in a way this feels like a loss, and losses hurt. Swift continues to make steady progress towards safety, new platforms and interop with other languages and heaps of new features -- all good things.
C++ is not my forté, so I am not ever really in the know for what is needed and what is not needed. I know a feature exists, I use it. Interop seems to works fine, for me.
I am glad that in their write up they didn't spend time trashing Swift. It sounds like Swift just didn't fit their needs. And that is OK. Swift will continue to come along.
With that said, they stated "We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited."
I build for Linux, WASI, Apple systems. I felt like it all works fine. What parts of C++ inter-op do you think they were lacking? Was Swift lacking in better GUI support on other platforms for them, or was it having to do with the product that Swift produces, binary size, SDK availability, build time, et cetera?
If I were to wager, I always felt like Swift GUI libraries were lacking in features, but I feel like someone on their team would have had the skills to iron out some of the shortcomings of those projects.
I am curious to understand it, not because I want to suggest that the Swift team and volunteers aren't doing enough, they absolutely are. I just wanna peer into what might have dissuaded them.
Maybe in the process of understanding it, we can mourn what might feel like a loss.
They have a tracking issue (now closed) that has links to many open swiftlang issues which would be a place to start looking at concrete issues.
Looking at this objectively, this is a clean-cut case of "if they wanted to they would" (in my words: "skill issue"). Swift as a programming language isn't holding ladybird back to any meaningful degree yet, if at all. They wanted interop but went with writing completely new code in a different language. They could've chosen Swift but didn't.
As an avid ladybird follower, this is disappointing but I still want them to succeed. I am looking forward to seeing their upcoming videos about its progression in the coming months (and new sponsors 
).
Naaah, I'm sorry, it's not the same at all. You can have private imports, but the module map produced for your module will still reference all the private imports inside, and the downstream dependencies secretly also need to compile against your private imports too - they have to spend time resolving them.
However, @_implementationOnly import is omitted from module-map and it's the only real hope for a big serious project to achieve reasonable compilation times. Right now at work I have a library that takes 2 minutes 30 secs. to compile, 2 minutes of which is resolving transitive private dependencies.
We absolutely need referential binding of value type instance members to local scope, such as referential binding of associated values of an enum case. Without it, you can not use ~Copyable and comfortably use all of Swift capabilities at the same time. You didn't mention ~Copyable of course, @camcaine, but I imagine this can be put on the same list.
I see... well... I'm sorry for saying that Swift on Android is pointless. -- sigh, I just wished, you know...; you care about Swift on Android and you do stuff towards it, but the person that cares about @_implementationOnly import, it's only one person, and he is busy with other stuff (no beef with him, I know he is essentially doing it out of the kindness of his heart, and he is busy), and there is no one else to do this push to do this necessary work, but him. Like, I realize now, that Swift community is not a centralized hive mind, but there are only individual people that push specific aspects of the ecosystem forward... Damn I wish I was good enough to be a compiler engineer... To iron this kind of level of issues.
Are you building with library evolution enabled? Documentation
I have this old project: GitHub - Cyberbeni/TypedNotificationCenter: Typed version of Apple's NotificationCenter to avoid forgetting setting parameters in the userInfo dictionary and needing to handle not having those parameters.
I opened the xcodeproj and added DeviceKit as an spm dependency and added it to all the framework targets.
I added internal import DeviceKit and ran ./create-xcframework.sh and there was no import DeviceKit in the swiftinterface files inside the xcframewotk. If I changed the import to public, I got a warning that my public interface is not using it and after recreating the xcframework, it was included in the swiftinterface file.
I'm using Xcode 26.2
I need it with library evolution disabled, so non-resilient modules, because resilient modules have all sorts of performance disadvantages. I need this to work in this very specific way, which is the most hard to implement. As for your example, do you build your module with library evolution on or off? Is memory layout of public structures in your project affected by size of a type from the DeviceKit? I was under an impression that a certain combination of these answers (and in fact, my current situation) is where suddenly it turns out that, yeah, we need @_implementationOnly import in non-resilient modules to improve compilation times without hurting anything else.
Anyway, this is not a new topic for me, and in this thread I didn't want to troubleshoot, but to raise awareness of [Pitch] Allow non-resilient modules to hide dependencies to clients.
Are those performance disadvantages measureable? I know that information is part of the marketing material for library evolution but haven't seen any actual benchmarks yet.
You could always just use library evolution for debug builds and internal distribution for release builds.
It's a totally reasonable thing to not want to use library evolution at all but still be able to prune dependencies that are not exported by APIs, if you're building an entire binary from source and have no plans to evolve libraries independently of the binary. The language and compiler should support this (and this has been acknowledged by folks who work on the compiler).
This isn't really the thread to delve deeper into that topic; one is linked just above.