Chains like Starbucks and McDonald's are popular for a reason. They make products people like. They have optimized for scale and cost. They provide consistent product and service, especially when traveling.
In the medium-sized town where I grew up, we always loved it when a new chain restaurant opened up in our town. They made us feel like we got the same options as the big cities.
Observables are great, and are indeed the stream equivalent to Tasks. But the await/async keyword compilation doesn't support them. I think that's the parent post's point.
The one advantage of C#'s async/await over Go's CSP is that by exposing the underlying Tasks, you can take more control over how the continuations get executed. The result of this is that it's easy to have async code that all runs on the same thread (usually the UI thread) even while it calls a function makes a network request that gets scheduled to a background thread.
Go's model doesn't give you as much control over which thread a particular operation gets assigned to. It's not theoretically impossible, I suppose, but it's hard to imagine what a simple API for it would look like.
But yes, if this particular problem were solved in an elegant way, I would also prefer the CSP model. It makes it so you don't have to worry about which operations are async or not.
"In general, a character can be represented in 1 byte or 2 bytes. Let's say 1-byte character is ANSI character - all English characters are represented through this encoding. And let's say a 2-byte character is Unicode, which can represent ALL languages in the world."
No. A character can be three or four bytes. I think he meant ASCII, not ANSI. And no, two byte characters are not "Unicode". I feel like this article might do a disservice to folks who aren't totally clear about Unicode before theyread it. I would strongly recommend reading Joel Spolsky's "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" and being totally clear on that before trying to read this.
I should point out that the Parse iOS SDK has been built on top of this task framework for over a year, and the Facebook iOS SDK has been using it for months. So it has been battle-tested in at least thousands of production apps. Maybe promises aren't appropriate for every single situation, but we certainly haven't noticed anything that makes them particularly tricky in iOS.
"In terms of academia and career, engineers at companies like Google are used to doing really well and rejection is not a frequent event in this part of their lives. They probably got into one of their top choice schools, where they then left to work at one of their top choice companies."
Is there any evidence that this is actually true? It certainly wasn't true for me.
PFObject subclassing and a more comprehensive offline solution are both very high on our list of features we would like to add. We're just taking our time to make sure we get them right. :)