As a flippant reply to a heartfelt paean, @tkremenek any chance of hiring this guy?
1 Like
@esummers: I know, that in theory you can already replace Node.js, not only with wasm, but also at the server-side. In my opinion, the people just don't write any libraries or stuff with Swift, as long as it isn't available in a simple way like Node.js. My hope is, that a compiler for Windows, all other Linux distributions then Ubutunu will really bring the chance, that there will be more Swift on the servers.
1 Like
I agree that broad platform support is very important to build a community interested in Swift on the server. Linux support is probably good enough since it supports Docker, but certainly supporting more distributions would be nice. Tracking this, it appears that Windows support is getting there. It will probably be useable in about a year. Swift 6 will add some important features for server-side swift. I think in 3 years the language will be ready to be a real contender in this space and not just us Swift fans that might use it even if it is more difficult.
The big milestone that was just hit was that SPM wasn't up to the challenge until recently. That affected the community for both server and in general. With Xcode integration and support for artifacts coming soon, I think things are finally to the point where it will take off. Stable ABI means that the operating system will start embracing Swift more. I'm starting to see many more Swift packages since Xcode 11. NIO was also a big step toward creating a server side ecosystem.
TensorFlow has been both embracing Swift and working on adding C++ interop to Swift. This could also be interesting. If Swift ends up being good at both a web server and machine learning and systems programming (including existing C++ libraries) this could make it good for niches that no other web server platform can do easily. Particularly when it comes to micro-services. In fact I think it will be micro-services that will see the most interest initially.
EDIT: In fact it wouldn't be surprising to me if Google uses Swift for micro-services. I believe they currently use mostly C++ and Golang. If Swift can interop with C++ well enough, it may make sense for them to use it in places that Golang isn't a good fit. There obviously is precedent for this at Google with Tensorflow adopting Swift with it's decent performance and the fact the language was built with interop in mind for the Objective-C transition which is now being expanded to Python and C++. ARC also makes interop easier with other languages.
2 Likes
What part of the the term 'concurrency' does not imply first-class async support?
Also, speaking for myself, while async-await (or something like it) would be cool, variadic generics and an improved ownership model would be far more beneficial for my day-to-day work.
4 Likes
No, it does not. Concurrency in Computer Science is defined as breaking up tasks into one or more units that can be run independently while converging on the same result. Locks are only common when concurrency is accomplished via either explicit parallelism (e.g. OS threads) or managed runtimes (e.g. green threads).
The Async-Await concurrency model (which has been strongly implied to be the direction Swift is heading in) is a return to Cooperative Multitasking via coroutines, and while it doesn't completely eliminate explicit locks, it does drastically reduce the need for them.
You can read more about the model here: Asynchronous programming. Cooperative multitasking - Blog | luminousmen
You can also read the tentative Swift Concurrency Manifesto here: Swift Concurrency Manifesto Ā· GitHub
3 Likes
I would just be careful asserting you speak on behalf of, or know what, "the average Swift developer" wants.
4 Likes
That is why I said "likely". From my experience working with Swift from 1.0, this has been a very common pain point for me and my teams, so it is my intuition based on my experience. Prioritizing any of these items is an assertion of what we think will benefit the most developers. Perhaps a community poll would be better than all of us guessing?
My apologies, I was misinformed on the precise definition of concurrency vs parallelism. The recent proposal I mentioned was actually low level atomics, not about concurrency in general. My bad! I will admit the years long delay in implementing the concurrency manifesto is frustrating and I posted in haste. Thanks and have a nice day.
Honestly, as an every-day Swift developer, I've missed heterogeneous generics far more often than I've missed async/await.
28 Likes
I second this. If we had at least variadic generics, parameterized extensions, typed throws and generic associated types, Iād probably be very happy for a while. There are more generic features that I wish we had now, but the mentioned ones are more interesting for me.
25 Likes
+1. I miss type system features way more than async / await. I'm pretty happy with the current model I'm using for async programming. TBH, I'm not sure whether I'd even use async / await as it's been proposed much at all. I would like to see syntactic sugar that would work with a Zio-style IO type, but async / await as it has been proposed would not do that.
9 Likes
Frankly I'd just like the stuff we already have to work better. +1 on improving the debugger.
6 Likes
Been wanting to hear this from others for a while. I've read the Concurrency manifesto about 6 times. At first I was hugely excited. Then Combine and SwiftNIO came along and frankly I just don't see why people are so anxious for async/await now. It seems to me that Promise/Future pairs + flatMap from those packages gets me everything that the manifesto outlines for async/await for only in a much more flexible form. And it does it without adding yet more keyword cognitive load to the language.
I'm still excited about the Actor model parts of the manifesto and would definitely like to see the language move to direct support of that, but given that I've had second thoughts on async/await I don't really trust my judgement there anymore either.
So I too would prefer to see the generics manifesto completed as a much higher priority than async/await.
10 Likes
Would you mind sharing what approach you're using?
I think what I find frustrating is that because there is no canonical Swift solution for async programming today (aside from GCD + callbacks), everyone chooses their own abstractions and we end up with a fractured ecosystem. You may need to learn 3+ solutions (which all have subtle differences) to be generally comfortable moving between projects or platforms. I don't think we necessarily need new language constructs, just an async/streams implementation that is first party, open source, and portable.
Of course, this is coming from an application developer who happens to write tons of async logic every day. Someone building RxSwift would no doubt be more excited about variadic generics (for zip, etc). How as a community do we prioritize these different use cases? Or is it the squeaky wheel that gets the oil?
2 Likes
It's in the same ballpark as PointFree's composable architecture. I use Elm-style stores and async effects that feed actions back into the store.
The work the Point Free team is doing is excellent and deserves much greater awareness in the community.
The need for first class async programming in Swift is largely motivated by a more fundamental problem: app architecture. It is as clear as day when you consider the examples in the Concurrency Manifesto in light of the Composable Architecture framework.
SwiftUI goes a long way to addressing part of the problem with app architecture but the model layer is undefined. If the standard library was more opinionated about the model layer of app architecture, I expect much pain to be eased.
The Composable Architecture framework is a start but it is still too technical. An average developer can't just pick it up and start running with it because they need to learn a handful of exotic concepts in functional programming (what's a monoid? what's a prism? what's a lens? etc). The Swift community, Apple or someone needs to provide a library that enables developers to design a well architected app intuitively (without much deliberation).
10 Likes
We have golang style coroutines in Swift for quite a while now. GitHub - Zewo/Venice: Coroutines, structured concurrency and CSP for Swift on macOS and Linux.
I'm currently updating the library to the latest Swift version.
6 Likes
While this is a really great project, it has the same issue that all other Swift coroutine libraries have. It relies on setjmp and longjmp, both of which are considered undefined behaviors in Swift (this is the primary reason that Zewo has basically dropped out of SSS). This, if I am correct, still applies to the custom implementations of those methods by libdill.
I'm not too well versed in the top myself, so if you want to know more I would suggest talking to the people from the NIO team.
Zewo's fork of libdill deals with the arc issues that @Joe_Groff mentioned. We manually push and pop the autorelease pool as can be seen here:
Although Zewo is not being actively maintained openly, it is currently being used by the healthcare company I work in since 2016 with no issues. Like I said I do plan to update the libraries soon.
Now, making this post relevant to the topic. I would love to see coroutines and structured concurrency being officially supported by Swift.
7 Likes
setjmp and longjmp are not safe to call directly from Swift, but using them as part of a runtime library that otherwise maintains the invariants Swift code (and the underlying OS) expects should be OK. If the coroutine library nevers resumes Swift code more than once at the same point (which could cause over-retain or -releases, or mess up OS stack maintenance), and doesn't ever try to "recover" by stopping execution of Swift code in a nested frame then resuming at an outer Swift frame as if an exception unwound the stack (which could leak memory, and also mess up OS stack maintenance), and it plays well with the invariants that some OSes and runtimes like Windows and Darwin libdispatch expect of execution contexts, then it shouldn't be any less unsafe to use with Swift than with other languages.
13 Likes