I'm not assuming that. If anything, I assumed that most people defending them are American, and that Americans are wrongly interpreting "American suburbs suck" as "suburbs suck" because American suburbs are the only ones they know.
Some people like them, sure. I suspect that much of it is just cultural momentum at this point, though, where people are unaware of the possibility of a different format, or don't have the option available, and that given a choice to live in a Euro-style or American-style suburb that were otherwise in a similar situation, many Americans would choose the European-style one. Might even split 50/50.
Seriously? Most late-20th century American subdivisions are built on the scale of a section, which is a mile on each side. Each section typically has a strip-mall type car-centered shopping area with a grocery store at one corner. Due to the fractal layout of the dead-end streets and lack of walking facilities it is generally at least a mile from any of the houses to any of the grocers. And that's for th people who are willing to walk down the side of a giant street-cross-freeway without sidewalks.
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.
I understand the sentiment, it does feel good to know your town is 'on the map' so to speak, but I do think there's something to be said for supporting local businesses too.
To give an example, I grew up in a small city. We had a McDonalds, a Burger King, etc... but we also had local burger places that made tastier burgers than those from the big chains. I found those local burger places gave me more pride in where I lived than just that we had what lots of other places had.
I guess what I'm saying is that local shops can add more to a sense of place than the ubiquitous chains. Is that something you'd agree with?
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.
It was during a presentation on the NDC developer conference a few years back, when the feature was new to C#. I remember thinking it was one of the best presentations that year, but right now I don't remember what year it was, and I can't find any past agendas to search either.
NDC posts their videos online after each conference, and I did a quick skim. I think it may be this session here, but I haven't double-checked:
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.
A huge problem with C#'s Async feature that I hope gets resolved (and, obviously that this failure pattern is not ported to Javascript): Explicitly blocking during a function that uses async somewhere inside (a sub-function) will cause your application to deadlock. It is extremely surprising that .NET does not handle this (abet novice) design mistake in a graceful way. (For example, checking if a thread is blocked before attempting to schedule tasks to it)
This was one of my main worries about Go when I evaluated it back in 2010. Most green threads implementations have an explicit determinism model, and it's typically straightforward to reason about and depend on execution order and suchlike, much as you can with plain asynchronous code, but with Go there didn't appear to be any guarantee when or how your code ran.
In any case I suppose many styles of Go program will exhibit accidental determinism, but it still seems too difficult to depend on as randomness can be introduced simply by invoking the wrong function, or by using a different runtime version, which to me feels comparable to the hazards of raw multithreading.
They might look related in terms of various "idioms/building blocks" used but they cater to two completely different programming languages i.e. Objective C/C++.
"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.
