[PopsiclePete]

I can't believe Apple would release a brand-new language with zero baked-in support for concurrency. In this day and age? Looks like developers will have to resort to 2nd grade efforts like GCD. I just don't get it. There's no excuse for it. Port Go's channels and go-routines to it, or something else, but come on - it's 2014, not 1998?

[threeseed]

If you think about it none of what you said really makes sense.

In what way is GCD not a concurrency mechanism ? And why would you port Go's channel/routine model when it is less flexible than the Actor model ? And even then what type of mobile applications require that level of concurrency ? I've built about 20 mobile apps and not once needed anything more than a few background tasks.

[matthewmacleod]

I don't really thing GCD counts as "2nd grade" - have you actually used it? It's really nice.

[alayne]

Swift has GCD and NSOperationQueue which work well. Why marry yourself to that functionality if you can externalize it with the potential to change it in the future?

Why doesn't Go have generics and sum types?

[pjmlp]

> it's 2014, not 1998?

I could say the same of Go as a language, given the disdain for all what modern languages offer.

With modern languages where library types can be treated as first class types, concurrency can be exposed via libraries.

[easytiger]

Well they are the people who sold a phone with no support for background tasks. They can do as they please.

[threeseed]

iOS supports the most common background tasks.

[easytiger]

It didn't though for many years

[gress]

Which was a user-friendly decision during the period where android phones frequently died after only 4 hours of use.

[easytiger]

> frequently died after only 4 hours of use.

I've never had a phone die after 4 hours of use and I've had the 1st Gen iphone and the HTC G1