I had suspected this would happen, I haven’t got into Swift yet (I’m mostly doing embedded C still) but Swift finally seems to have just ticked off some niggles that makes it a much stronger contender. Things like not having official Debian builds (there were Ubuntu etc.), not being able to run under other C libraries like musl (like if you want to run in Alpine Linux containers), not really being able to run embedded etc. basically all being fixed in the last release (or starting the process, like with the embedded subset). Add in the newish C++ interop and it does seem much more attractive now as a pin ergonomic, memory safe, cross-platform language at all levels of the stack!
(This is of course by design, Apple intend to use Swift from everything from firmware of things like the Secure Enclave chip, through to the kernel, through to all the apps, but to be able to bring it in gradually with the interop, so not having to rewrite everything from scratch).
Honestly, Swift seems like such a nice language. Most of the performance and power, great interop, but more directed at application development than Rust (with e.g. refcounting being the default).
But as they say, you choose a language for its ecosystem, not for the language itself.
It would be great if Swift’s open source ecosystem for stuff other than app development grew. It does indeed seem like Apple is pushing for it with stuff like Swift for embedded. The fairly recent presentation about starting to move FoundationDB to Swift[0] was also very interesting. A follow-up on that at some point would be quite interesting to see too, and would inspire confidence if the process is going well. Arc is also a nice example of a cross-platform app written in Swift, with their fairly recent addition of Windows support.
Either way, fingers crossed, and very happy with TFA.
PS: does anybody have experience with async/await in Swift? Is it pleasant to use?
> you choose a language for its ecosystem, not for the language itself.
Given that this is Ladybird, which came out of the Serenity OS project (which didn't allow any external code at all), it's not surprising that they didn't prioritize ecosystem when picking a language. I believe they're planning on being less strict about that with Ladybird, but the culture of independence is likely still there.
I have about 30k lines of Swift in my app + Matrix sdk, all heavily using async/await. Plus another couple kloc in a Vapor API backend.
Swift async/await is quite nice.
The Actor stuff is IMO way oversold - reentrancy issues make it not actually useful for the things that they claim, like querying a database. It’s still a useful construct to have, you just need to be aware of what it does or doesn’t provide.
Found an interesting article about the internals of async specifically[0], also the docs[1].
TLDR: Seems like it uses a global thread pool, where each async method call yields to the runtime. Additionally, you get actors which are special classes with serialized method calls, and everybody other than itself has to call those methods as async. Additionally, you can have custom executors, who, if I understand correctly, still only pass tasks to the global thread pool, but can influence the scheduling order. Finally, you can force functions/actors to run on the main thread (outside of the thread-pool) as iOS requires the UI to run on the main thread.
Interestingly (from an API evolution perspective), async protocol functions can be implemented in classes by synchronous functions, as async in swift means "this could be async". Which plays well with the fact that async functions can call sync ones, but not vice-versa.
Additionally, it has cooperative cancellation (you can basically check if you've been cancelled and react accordingly). Concurrency is by default structured, and cancelling a parent task will cancel its children.
(This is of course by design, Apple intend to use Swift from everything from firmware of things like the Secure Enclave chip, through to the kernel, through to all the apps, but to be able to bring it in gradually with the interop, so not having to rewrite everything from scratch).