Comment by cube2222 | Hacker News Reader

Comment by cube2222 | Hacker News Reader

Parent Full thread

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?

[0]: https://www.youtube.com/watch?v=ZQc9-seU-5k

> 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.

Totally agreed on that. What I hope will happen is that they will be part of building that ecosystem.

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.

[0]: https://swiftrocks.com/how-async-await-works-internally-in-s...

[1]: https://docs.swift.org/swift-book/documentation/the-swift-pr...

Reply on news.ycombinator.com