5 ms·

Very nice to see some activity on the server side of things for Swift. But it would be important that major players really get on board and create some kind of

by dep_b 9y ago

Very nice to see some activity on the server side of things for Swift. But it would be important that major players really get on board and create some kind of standard. I would love to see something like the Phoenix framework for Swift.

josephg 9y ago
Absolutely. I tried writing some server side swift code about a year ago, and at the time there were 4 competing async networking (raw / http) frameworks. Each one used similar but incompatible primitives to handle concurrency. (Libdill / threads / libdispatch / kqueue). As a result anything written on top of any of those libraries would stay tightly coupled to that library. I was worried I'd pick the wrong winner and need to rewrite all my code in the next couple years of churn. For comparison, Nodejs and Go both have streaming IO, networking and HTTP built into their core libraries. As a result interoperability between 3rd party libraries in those ecosystems is way better. So I'm excited to see a canonical async promise library out for swift! Between this and Rust's futures 0.2 RC coming out last week[1] it looks like the new generation of modern C-replacement languages are starting to mature enough for useful network services to be written on top of them. I'm excited to see what the next few years will bring. And I'm really looking forward to using all the language features Swift and Rust have that are missing from my standard workhorse languages. (Parametric enums + pattern matching! Yay!) [1] http://aturon.github.io/2018/02/27/futures-0-2-RC/ http://aturon.github.io/2018/02/27/futures-0-2-RC/
- dep_b 9y ago
  I'd say Swift isn't really a C-replacement as it uses ARC which is slower and doesn't need manual management to work (except for a few weak references here and there). It's generally/potentially faster than Java and C# code as it's pre-compiled and it can use C and C++ libraries (perhaps also Rust?) without bridging cost. But ARC is a reliable and constant but slow way to manage memory. The good thing about ARC is that it's the same every time, no weird GC peaks at sometimes difficult to predict intervals.
  - terhechte 9y ago
    Only temporarily. One of the next Swift versions (my bet is on Swift 6) will include an optional memory ownership model: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan... It will not have lifetimes but still allow to opt out of ARC for performance critical code.
    - dep_b 9y ago
      That's interesting. I bet a lot of people doing performance critical stuff like graphics or audio are going to be interested in this.
sudhirj 9y ago
Perfect ( http://perfect.org/ http://perfect.org/ ) is already trying to be the Phoenix for Swift.

by dep_b 9y ago

josephg 9y ago

Absolutely. I tried writing some server side swift code about a year ago, and at the time there were 4 competing async networking (raw / http) frameworks. Each one used similar but incompatible primitives to handle concurrency. (Libdill / threads / libdispatch / kqueue). As a result anything written on top of any of those libraries would stay tightly coupled to that library. I was worried I'd pick the wrong winner and need to rewrite all my code in the next couple years of churn. For comparison, Nodejs and Go both have streaming IO, networking and HTTP built into their core libraries. As a result interoperability between 3rd party libraries in those ecosystems is way better. So I'm excited to see a canonical async promise library out for swift! Between this and Rust's futures 0.2 RC coming out last week[1] it looks like the new generation of modern C-replacement languages are starting to mature enough for useful network services to be written on top of them. I'm excited to see what the next few years will bring. And I'm really looking forward to using all the language features Swift and Rust have that are missing from my standard workhorse languages. (Parametric enums + pattern matching! Yay!) [1] http://aturon.github.io/2018/02/27/futures-0-2-RC/ http://aturon.github.io/2018/02/27/futures-0-2-RC/

dep_b 9y ago
I'd say Swift isn't really a C-replacement as it uses ARC which is slower and doesn't need manual management to work (except for a few weak references here and there). It's generally/potentially faster than Java and C# code as it's pre-compiled and it can use C and C++ libraries (perhaps also Rust?) without bridging cost. But ARC is a reliable and constant but slow way to manage memory. The good thing about ARC is that it's the same every time, no weird GC peaks at sometimes difficult to predict intervals.
- terhechte 9y ago
  Only temporarily. One of the next Swift versions (my bet is on Swift 6) will include an optional memory ownership model: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan... It will not have lifetimes but still allow to opt out of ARC for performance critical code.
  - dep_b 9y ago
    That's interesting. I bet a lot of people doing performance critical stuff like graphics or audio are going to be interested in this.

sudhirj 9y ago

Perfect ( http://perfect.org/ http://perfect.org/ ) is already trying to be the Phoenix for Swift.