5 ms·

As someone preparing to transition from C# to Swift dev, async/await was a big missing piece. I’ll be curious to see how quickly the ecosystem picks it up as I

by nxc18 5y ago

As someone preparing to transition from C# to Swift dev, async/await was a big missing piece. I’ll be curious to see how quickly the ecosystem picks it up as I move forward on my journey. My experience interacting with teams and devs targeting Swift is that when Apple says “jump” you jump. What do people already using Swift in production think?

toddh 5y ago
The @MainActor is nice. It was always bewildering to me that we still had put UI operations on the main thread by hand. I still don't get why we need @MainActor. The compiler should do some sort of flow analysis and do the right thing.
- coldtea 5y ago
  Then you have two problems...
Pulcinella 5y ago
We build a lot of REST based apps and are very, very excited to transition our internal networking framework to async/await. Currently we use GCD which can lead to a nightmare of closures as well as a lot of ugly indentation.
SirensOfTitan 5y ago
I worked with Swift extensively for a year and a half, and I absolutely adore the language. I think it does a lot right while avoiding more of rust's complexities (I am a rust n00b, so grain of salt). The problem with Swift (as of like 1.5 years ago when I stopped using the language daily) was its ecosystem. Swift package manager wasn't really used (at least for iOS apps), there was no real decent ecosystem outside the xcode world (no langserver, some server-side swift abstractions). I think Swift would really thrive if Apple were to give it some room to breathe in the open source community, but until Swift decouples itself more from Apple's own needs, I couldn't imagine using it for anything other than iOS development.
- armchairhacker 5y ago
  Two of my favorite languages are Swift and Kotlin. I basically always choose Kotlin, but I would actually like Swift more if it was supported more outside of Apple. Swift has the benefit of actual value types, no GC, and IME it's much faster. But it only runs on Apple's OS (technically there's support for Linux but people say it isn't good). Kotlin has access to all Java packages and runs on the JVM, and with Kotlin multiplatform JetBrains is trying to make it run on almost anything.
  - jolux 5y ago
    Swift is currently reference counted, which is more or less GC but worse because it’s not tracing/cycle-detecting.
    - favorited 5y ago
      Every design decision has tradeoffs. RC has its own significant upsides, like deterministic deallocation and a much lower memory floor for preventing world-pauses during tracing.
      - jolux 5y ago
        How is RC deallocation deterministic? Besides which I don't want to have to keep track of weak references, at that point I would rather just have a full ownership model: https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/main/docs/OwnershipManif...
        bjustin 5y ago
        I assume the grandparent was talking about how, as soon as the last reference to a refcounted object goes away, the object is deallocated. Pure Swift follows this rule though Objective-C code may not always do this due to things like autorelease pools.
        5y ago
moj 5y ago
Yes, async/await will be terrific. It's been a long time coming though; I've been expecting it 'real soon now' for over 3 years: https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 https://gist.github.com/lattner/429b9070918248274f25b714dcfc...
myko 5y ago
I still don't understand why I'd want to use async/await in a mobile/desktop app over something like Rx (Combine). Is there a good rundown on when to use one or the other?
- elpakal 5y ago
  also interested in async vs combine, but i’m the other way around - unless you want to fight for rx programming i see Combine being in a very weird place. it looks like existing Foundation stuff will be easy to change to async, and for teammates without rx experience Combine can be a big mental model shift. plus Combine doesn’t compile on Linux, which is a big deterrent for me when thinking about how I might want to approach a Swift command line app.
- dmitriid 5y ago
  async/await are trivial to understand and use. Anything Rx beyond the simplest of examples? Nope.
  - myko 5y ago
    Rx is very powerful and can be difficult to understand at first, especially if you haven't done a lot of programming in functional languages before. I'm not trying to argue about that though - I just want to know under what set of circumstances I should prefer async/await over Rx and vice versa.
- guacaswole 5y ago
  I wondered the same thing actually. After I read about async await I thought “Well, what’s the point in Combine then?”
  - akmarinov 5y ago
    It’s your choice - you want Rx - you do Rx. Everyone gets something.
    - myko 5y ago
eob 5y ago
I've been using Swift to build the server-side of NLUDB.com and async/await is the biggest item on my wish list. Maybe I just haven't learned proper EventLoopFuture-style development style, but you really seem to get stuck callback hell, similar to the early days of NodeJS. It's a bear on code readability. Re: the sibling comment about Combine -- I've heard great things about Combine but AFAIK it's still part of Apple's platform-specific layer atop Swift so the small group of us using Swift atop Linux can't use it (yet?).
elpakal 5y ago
love Swift, largely agree with most comments here and feel like async fills a big hole. > when Apple says “jump” you jump. just not with the betas
travisgriggs 5y ago
I'm trying to figure out where Swift is going. I maintain 3 relatively complex apps in it. When I first started coding on iOS, it was objective C. Objc was a poor mans Smalktalk, and when that didn't scale you did some inline C. Being quite familiar with Smalltalk and C, I was comfortable with this two basic computing models (everything's an object OR pointer/stack machine), I just had to do the Frankenstein dance of knowing when to employ how much of which. With Swift, I have a hard time getting a feel for what the unifying gestalt of the language is supposed to be. It's a better C! It's objects! It's functional! It's typesafe! It's protocols! It's async! It's closures! It's a better C++! It's modern! It's a systems language! It's a scripting language! It's for UIs! It's actors! It's declarative! It infers things! I get stuff done with it (obviously) and it's capable, but the effect has not been "it's a bird, it's a plane, it's Superman." It feels like some sort of anime shapeshifter caught in a cycle sometimes. Or a bogart. I keep hoping these are growing pains, intermediate steps, with a "long game" characteristic of Apple, but I'm not seeing it yet. Kotlin seems to be following a similar path, just a few steps behind in some places, and a few steps ahead in other.
- pjmlp 5y ago
  A common trait to any multi-paradigm language, I fail to see the problem. In fact, you could state the same complaints against Turbo Pascal on the MS-DOS days.
singularity2001 5y ago
Async await is the mistake of the decade. Not the concept of concurrency but the function coloring approach. See previous discussions for why this is such a bad idea. In short: concurrency belongs on the caller side, not the callee side. Go does it right, most others follow the dark path.
- dkdbejwi383 5y ago
  Interesting argument, do you have any links to said discussions on this topic?
  - smw 5y ago
    https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
    - dkdbejwi383 5y ago
      Appreciate it!

by nxc18 5y ago

toddh 5y ago

The @MainActor is nice. It was always bewildering to me that we still had put UI operations on the main thread by hand. I still don't get why we need @MainActor. The compiler should do some sort of flow analysis and do the right thing.

coldtea 5y ago
Then you have two problems...

Pulcinella 5y ago

We build a lot of REST based apps and are very, very excited to transition our internal networking framework to async/await. Currently we use GCD which can lead to a nightmare of closures as well as a lot of ugly indentation.

SirensOfTitan 5y ago

I worked with Swift extensively for a year and a half, and I absolutely adore the language. I think it does a lot right while avoiding more of rust's complexities (I am a rust n00b, so grain of salt). The problem with Swift (as of like 1.5 years ago when I stopped using the language daily) was its ecosystem. Swift package manager wasn't really used (at least for iOS apps), there was no real decent ecosystem outside the xcode world (no langserver, some server-side swift abstractions). I think Swift would really thrive if Apple were to give it some room to breathe in the open source community, but until Swift decouples itself more from Apple's own needs, I couldn't imagine using it for anything other than iOS development.

armchairhacker 5y ago
Two of my favorite languages are Swift and Kotlin. I basically always choose Kotlin, but I would actually like Swift more if it was supported more outside of Apple. Swift has the benefit of actual value types, no GC, and IME it's much faster. But it only runs on Apple's OS (technically there's support for Linux but people say it isn't good). Kotlin has access to all Java packages and runs on the JVM, and with Kotlin multiplatform JetBrains is trying to make it run on almost anything.
- jolux 5y ago
  Swift is currently reference counted, which is more or less GC but worse because it’s not tracing/cycle-detecting.
  - favorited 5y ago
    Every design decision has tradeoffs. RC has its own significant upsides, like deterministic deallocation and a much lower memory floor for preventing world-pauses during tracing.
    - jolux 5y ago
      How is RC deallocation deterministic? Besides which I don't want to have to keep track of weak references, at that point I would rather just have a full ownership model: https://github.com/apple/swift/blob/main/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/main/docs/OwnershipManif...
      - bjustin 5y ago
        I assume the grandparent was talking about how, as soon as the last reference to a refcounted object goes away, the object is deallocated. Pure Swift follows this rule though Objective-C code may not always do this due to things like autorelease pools.
        5y ago

moj 5y ago

Yes, async/await will be terrific. It's been a long time coming though; I've been expecting it 'real soon now' for over 3 years: https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 https://gist.github.com/lattner/429b9070918248274f25b714dcfc...

myko 5y ago

I still don't understand why I'd want to use async/await in a mobile/desktop app over something like Rx (Combine). Is there a good rundown on when to use one or the other?

elpakal 5y ago
also interested in async vs combine, but i’m the other way around - unless you want to fight for rx programming i see Combine being in a very weird place. it looks like existing Foundation stuff will be easy to change to async, and for teammates without rx experience Combine can be a big mental model shift. plus Combine doesn’t compile on Linux, which is a big deterrent for me when thinking about how I might want to approach a Swift command line app.
dmitriid 5y ago
async/await are trivial to understand and use. Anything Rx beyond the simplest of examples? Nope.
- myko 5y ago
  Rx is very powerful and can be difficult to understand at first, especially if you haven't done a lot of programming in functional languages before. I'm not trying to argue about that though - I just want to know under what set of circumstances I should prefer async/await over Rx and vice versa.
guacaswole 5y ago
I wondered the same thing actually. After I read about async await I thought “Well, what’s the point in Combine then?”
- akmarinov 5y ago
  It’s your choice - you want Rx - you do Rx. Everyone gets something.
  - myko 5y ago

eob 5y ago

I've been using Swift to build the server-side of NLUDB.com and async/await is the biggest item on my wish list. Maybe I just haven't learned proper EventLoopFuture-style development style, but you really seem to get stuck callback hell, similar to the early days of NodeJS. It's a bear on code readability. Re: the sibling comment about Combine -- I've heard great things about Combine but AFAIK it's still part of Apple's platform-specific layer atop Swift so the small group of us using Swift atop Linux can't use it (yet?).

elpakal 5y ago

love Swift, largely agree with most comments here and feel like async fills a big hole. > when Apple says “jump” you jump. just not with the betas

travisgriggs 5y ago

I'm trying to figure out where Swift is going. I maintain 3 relatively complex apps in it. When I first started coding on iOS, it was objective C. Objc was a poor mans Smalktalk, and when that didn't scale you did some inline C. Being quite familiar with Smalltalk and C, I was comfortable with this two basic computing models (everything's an object OR pointer/stack machine), I just had to do the Frankenstein dance of knowing when to employ how much of which. With Swift, I have a hard time getting a feel for what the unifying gestalt of the language is supposed to be. It's a better C! It's objects! It's functional! It's typesafe! It's protocols! It's async! It's closures! It's a better C++! It's modern! It's a systems language! It's a scripting language! It's for UIs! It's actors! It's declarative! It infers things! I get stuff done with it (obviously) and it's capable, but the effect has not been "it's a bird, it's a plane, it's Superman." It feels like some sort of anime shapeshifter caught in a cycle sometimes. Or a bogart. I keep hoping these are growing pains, intermediate steps, with a "long game" characteristic of Apple, but I'm not seeing it yet. Kotlin seems to be following a similar path, just a few steps behind in some places, and a few steps ahead in other.

pjmlp 5y ago
A common trait to any multi-paradigm language, I fail to see the problem. In fact, you could state the same complaints against Turbo Pascal on the MS-DOS days.

singularity2001 5y ago

Async await is the mistake of the decade. Not the concept of concurrency but the function coloring approach. See previous discussions for why this is such a bad idea. In short: concurrency belongs on the caller side, not the callee side. Go does it right, most others follow the dark path.

dkdbejwi383 5y ago
Interesting argument, do you have any links to said discussions on this topic?
- smw 5y ago
  https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
  - dkdbejwi383 5y ago
    Appreciate it!