4 ms·

This is a great writeup, wish I had it when I started with Flutter. BTW, I've written a couple Flutter apps now and this set of tools (Futures, async/await, Iso

by matt2000 8y ago

This is a great writeup, wish I had it when I started with Flutter. BTW, I've written a couple Flutter apps now and this set of tools (Futures, async/await, Isolates) covers my multithreading use cases in a really nice and safe way. By comparison, Grand central dispatch is pretty nice on iOS, but I really miss the first class async/await calls. Side note: How did they make an entirely new language for app development (Swift) and not build in async/await support? Kotlin co-routines seem to be a pretty nice solution on Android, but before that it was a bit of a mess. There was 4 or 5 different ways to do things async, they all interact in super complicated ways with the activity life cycle, and basically nothing is quite what you need. Side side note: Unity also does a really nice version of all of this with a single event loop and really powerful co-routines. Worth checking out sometime.

foota 8y ago
I'm not sure async await was as much in the limelight at the start of development on swift, but I could be wrong.
- ygra 8y ago
  It's been part of F# since 2007 and C# since 2013, so the feature was probably known at design time of the language. However, language design is always a complicated dance of trade-offs, so there's never a way to initially account for all features that are eventually desired and implemented.
guzik 8y ago
Swift 5 will most likely include async/await
- Apocryphon 8y ago
  Whenever that is. It was originally slated for the last year.
  - coldtea 8y ago
    We used to wait decades for any meaningful change in languages like C, C++, Java, JS, etc...
    - Dibes 8y ago
      I'm not sure how what we used to do or wait for is relevant now. Technology and it's pace isn't the same as it was decades ago, and I see no reason that we should hold it to the standard of that time.
      - coldtea 8y ago
        >I'm not sure how what we used to do or wait for is relevant now. Because whether a language is slow to evolve only makes sense relatively to some baseline rate. >Technology and it's pace isn't the same as it was decades ago, and I see no reason that we should hold it to the standard of that time. And yet still, today, popular languages take their time to get features like async/await. Python got it after 3.6 (so 20+ years on), JS only got it in 2017, C++ doesn't have it, Rust doesn't yet have it (it's coming), Java doesn't have it, C++ doesn't have it... Heck, Golang doesn't have generics and comfortable error checking still...
        Dibes 8y ago
        It really is a language by language basis. Many languages adopt features insanely fast, many insanely slow. JS for example has as of late has a very fast rate of change[1]. Or you could look at how Java has changed from 8->10 and all the new features added there. There are other languages like C that haven't changed much at all (to my knowledge). It isn't relevant to take the rate of change of other languages and apply it to another as an expectation. You would get a better metric by taking the rate of change of the current language in the context of the last year or two.
    - matt2000 8y ago
      Sure, but these were languages that arrived with at least one huge improvement over the languages that existed at the time. Dart's async/await coupled with Flutter's proper support of it in their SDK is that huge improvement for me in mobile dev. In my experience, Swift is lacking any particular major improvement over ObjC. It seems like async/await could have been that big step, and Swift probably shouldn't have been adopted until it was in place. Just wasn't worth it. I realize that's a controversial topic and I know people who love Swift, just from my perspective it was such an enormous cost without enough upsides to justify it.
jayd16 8y ago
Android screwed up by putting AsyncTask in their first set of documentation. Its easy to show demos with but hard to get right in a safe way. There are some interesting things that Unity coroutines do, like the idea that routines are tied to owners that are running them, so when the owner's life cycle ends, the coroutines no longer continue. However, as a whole I think there's a lot wrong with them. They're not any safer than Android's async functionality, they just make doing anything off the main thread almost impossible so threading issues are easier to deal with. The whole wait and continue functionality of them is also very frustrating in implementation with many exceptions and hacks.
coldtea 8y ago
>By comparison, Grand central dispatch is pretty nice on iOS, but I really miss the first class async/await calls. Side note: How did they make an entirely new language for app development (Swift) and not build in async/await support? By building it gradually and not rushing everything from the first day. That said: https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 https://gist.github.com/lattner/429b9070918248274f25b714dcfc...
- fauigerzigerk 8y ago
  I think this is a question of priorities rather than rushing things. Swift is a post Moore's Law language after all.
bsaul 8y ago
If you want to see the big picture regarding swift and concurrency i recommend reading : https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

foota 8y ago

I'm not sure async await was as much in the limelight at the start of development on swift, but I could be wrong.

ygra 8y ago
It's been part of F# since 2007 and C# since 2013, so the feature was probably known at design time of the language. However, language design is always a complicated dance of trade-offs, so there's never a way to initially account for all features that are eventually desired and implemented.

guzik 8y ago

Swift 5 will most likely include async/await

Apocryphon 8y ago
Whenever that is. It was originally slated for the last year.
- coldtea 8y ago
  We used to wait decades for any meaningful change in languages like C, C++, Java, JS, etc...
  - Dibes 8y ago
    I'm not sure how what we used to do or wait for is relevant now. Technology and it's pace isn't the same as it was decades ago, and I see no reason that we should hold it to the standard of that time.
    - coldtea 8y ago
      >I'm not sure how what we used to do or wait for is relevant now. Because whether a language is slow to evolve only makes sense relatively to some baseline rate. >Technology and it's pace isn't the same as it was decades ago, and I see no reason that we should hold it to the standard of that time. And yet still, today, popular languages take their time to get features like async/await. Python got it after 3.6 (so 20+ years on), JS only got it in 2017, C++ doesn't have it, Rust doesn't yet have it (it's coming), Java doesn't have it, C++ doesn't have it... Heck, Golang doesn't have generics and comfortable error checking still...
      - Dibes 8y ago
        It really is a language by language basis. Many languages adopt features insanely fast, many insanely slow. JS for example has as of late has a very fast rate of change[1]. Or you could look at how Java has changed from 8->10 and all the new features added there. There are other languages like C that haven't changed much at all (to my knowledge). It isn't relevant to take the rate of change of other languages and apply it to another as an expectation. You would get a better metric by taking the rate of change of the current language in the context of the last year or two.
  - matt2000 8y ago
    Sure, but these were languages that arrived with at least one huge improvement over the languages that existed at the time. Dart's async/await coupled with Flutter's proper support of it in their SDK is that huge improvement for me in mobile dev. In my experience, Swift is lacking any particular major improvement over ObjC. It seems like async/await could have been that big step, and Swift probably shouldn't have been adopted until it was in place. Just wasn't worth it. I realize that's a controversial topic and I know people who love Swift, just from my perspective it was such an enormous cost without enough upsides to justify it.

jayd16 8y ago

Android screwed up by putting AsyncTask in their first set of documentation. Its easy to show demos with but hard to get right in a safe way. There are some interesting things that Unity coroutines do, like the idea that routines are tied to owners that are running them, so when the owner's life cycle ends, the coroutines no longer continue. However, as a whole I think there's a lot wrong with them. They're not any safer than Android's async functionality, they just make doing anything off the main thread almost impossible so threading issues are easier to deal with. The whole wait and continue functionality of them is also very frustrating in implementation with many exceptions and hacks.

coldtea 8y ago

>By comparison, Grand central dispatch is pretty nice on iOS, but I really miss the first class async/await calls. Side note: How did they make an entirely new language for app development (Swift) and not build in async/await support? By building it gradually and not rushing everything from the first day. That said: https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 https://gist.github.com/lattner/429b9070918248274f25b714dcfc...

fauigerzigerk 8y ago
I think this is a question of priorities rather than rushing things. Swift is a post Moore's Law language after all.

bsaul 8y ago

If you want to see the big picture regarding swift and concurrency i recommend reading : https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...