bklimt

Why are you assuming that none of us defending suburbs are American? There's a reason so many people like to live in them.

In every suburb I've lived in, whether in Austin or Pittsburgh or San Jose, there has been a grocery store within walking distance.

I have lived in smaller cities where that's not the case, but not in the suburbs.

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.

Nope, every single programming language and computing interface is an attempt to avoid writing machine code. :)

As a person with a toddler and 2 very talkative simanese cats, I cann tek k tiy= lplease just let me go back to lsepp

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.

He's 14, not 12.

How does this project relate to Facebook's other futures/promises library, Bolts?

https://code.facebook.com/posts/225525624316574/building-and...

"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.

There is a fork of CoffeeScript called IcedCoffeeScript that adds something similar: http://maxtaco.github.com/coffee-script/

> you are nowhere near familiar enough with Go to be justified in doing so

Haha, I agree. I wrote it mostly to try to get my thoughts straight, and didn't expect it to be posted to Hacker News. :)

But my criticisms are that these things make Go hard to learn. It may be a great language once you get everything straight.

> No, channels are reference types, too.

Ah, good to know. That wasn't clear to me from my first reading of the docs, but you're definitely right.

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. :)