6 ms·

I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is

I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. As much as I actually do enjoy working with Swift (real type classes!!), there are some parts that are a big WTF.

slavapestov 6y ago
> they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. This is exactly what the new async/await feature solves though. Actors are built on top of that.
- ragnese 6y ago
  Yeah, I know. I'm just lamenting how long it took to get to async/await. It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO.
  - zepto 6y ago
    They already had GCD and Operation provided by the platform, which worked perfectly with Swift, and dealt with concurrency very nicely. They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.
    - ragnese 6y ago
      I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or implementing Operation, there's no where to allow a `throws` function. Very similar problem to Java with checked exceptions and closures. The early versions of Swift didn't even have a standard Result type, IIRC. So even today, you will see some Swift functions that have `throws` in the signature and some that return `Result<T>`. It was always awkward.
      - zepto 6y ago
        They work perfectly in that they are not buggy, and they are efficient and reasonably straightforward to use and work as designed with Swift. I agree that they are not idiomatic, which is the point I’m making. There was a perfectly working solution that had no barriers to its use with swift, so it made sense not to rush the replacement.
        ragnese 6y ago
        If you agree that it's not idiomatic (and maybe I can get you to agree that it's more than just non-idiomatic when it comes to async operations that can fail), then are you actually refuting my original comment: "It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO."? Maybe it was the right call in the end (I'm of the opinion that it literally doesn't matter. Apple could ask us to develop in COBOL or even something as crazy as Objective-C and we'd all still do it), but I still think it's fair to say it was weird/surprising to have awkward/difficult async tools for an official mobile OS language.
        zepto 6y ago
        Having developed shipping apps in swift 1.0, using GCD, it wasn’t any more awkward than using GCD with objective C, indeed generally it was easier because Swift is more concise. I guess in relation to your original statement, I am refuting it. They had a strong solution which was pretty easy to use, and as good as the language they were replacing, and well integrated with the platform. The idea that they ‘didn’t have a strong solution’ doesn’t really hold from my point of view. It was strong, and working which gave them the luxury of time to develop an idiomatic solution as the language matured. If there really hadn’t been a strong solution in place, I would have agreed with you.
ogre_codes 6y ago
> I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. It is frustrating, but it seems like they are finally getting there. It’s frustrating since a language like Go had a good concurrency model almost from the start. But Go had different constraints and arguably has less surface area to cover.
- dwaite 6y ago
  Go is arguably a simplistic language built _around_ a simplistic concurrency model. Go is twice as old (since initial public release) and still doesn't have decent support for generalized algorithms, for example. They have struggled just as long to come up with a more usable error model.

slavapestov 6y ago

> they still don't have a stable async/concurrency story besides callbacks. What's more is that they actually chose an error handling mechanism that doesn't even work with callbacks/closures! So sometimes you have a throwing function and sometimes you return a Result. This is exactly what the new async/await feature solves though. Actors are built on top of that.

ragnese 6y ago
Yeah, I know. I'm just lamenting how long it took to get to async/await. It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO.
- zepto 6y ago
  They already had GCD and Operation provided by the platform, which worked perfectly with Swift, and dealt with concurrency very nicely. They weren’t under any pressure at all to have any other ‘async’ story early on and so intentionally chose to focus on other fundamentals and take their time to build something that would be well designed and additive.
  - ragnese 6y ago
    I argue that GCD, etc, don't actually work perfectly with Swift, though. Swift functions use a flavor of "checked errors" in the function signature via the `throws` keyword. When you're passing around callbacks or implementing Operation, there's no where to allow a `throws` function. Very similar problem to Java with checked exceptions and closures. The early versions of Swift didn't even have a standard Result type, IIRC. So even today, you will see some Swift functions that have `throws` in the signature and some that return `Result<T>`. It was always awkward.
    - zepto 6y ago
      They work perfectly in that they are not buggy, and they are efficient and reasonably straightforward to use and work as designed with Swift. I agree that they are not idiomatic, which is the point I’m making. There was a perfectly working solution that had no barriers to its use with swift, so it made sense not to rush the replacement.
      - ragnese 6y ago
        If you agree that it's not idiomatic (and maybe I can get you to agree that it's more than just non-idiomatic when it comes to async operations that can fail), then are you actually refuting my original comment: "It's weird for the official language of a mobile app ecosystem to not have a pretty strong async story pretty early on, IMO."? Maybe it was the right call in the end (I'm of the opinion that it literally doesn't matter. Apple could ask us to develop in COBOL or even something as crazy as Objective-C and we'd all still do it), but I still think it's fair to say it was weird/surprising to have awkward/difficult async tools for an official mobile OS language.
        zepto 6y ago
        Having developed shipping apps in swift 1.0, using GCD, it wasn’t any more awkward than using GCD with objective C, indeed generally it was easier because Swift is more concise. I guess in relation to your original statement, I am refuting it. They had a strong solution which was pretty easy to use, and as good as the language they were replacing, and well integrated with the platform. The idea that they ‘didn’t have a strong solution’ doesn’t really hold from my point of view. It was strong, and working which gave them the luxury of time to develop an idiomatic solution as the language matured. If there really hadn’t been a strong solution in place, I would have agreed with you.

ogre_codes 6y ago

> I feel like it's really lame that its Swift version 157 or whatever and they still don't have a stable async/concurrency story besides callbacks. It is frustrating, but it seems like they are finally getting there. It’s frustrating since a language like Go had a good concurrency model almost from the start. But Go had different constraints and arguably has less surface area to cover.

dwaite 6y ago
Go is arguably a simplistic language built _around_ a simplistic concurrency model. Go is twice as old (since initial public release) and still doesn't have decent support for generalized algorithms, for example. They have struggled just as long to come up with a more usable error model.