How Facebook pushes updates to the site - <AUTHOR> http://www.facebook.com/video/video.php?v=10100259101684977&oid=9445547199&comments <comment><USER2> I loved this video. Gatekeeper blew me away.

Summarized some of the highlights here if you don't have time to watch:

[http://agilewarrior.wordpress.com/2011/05/28/how-facebook- pu...](http://agilewarrior.wordpress.com/2011/05/28/how-facebook-pushes-new- code-live/)

<comment><USER3> I thought he said perforce and git, not subversion and git.

<comment><USER4> Then corrected himself to subversion and git.

<comment><USER3> Ahh, thanks. I wasn't listening that closely.

</comment></comment></comment></comment><comment><USER5> I'm pretty impressed by the "push karma" system for gauging how risky individual engineers' commits are on average.

Here's another (much shorter!) video where Chuck Rossi talks about push karma very briefly: [https://www.facebook.com/video/video.php?v=778890205865&...](https://www.facebook.com/video/video.php?v=778890205865&oid=9445547199&comments)

</comment><comment><USER6> I like how their entire development cycle revolves around people getting drunk on weekends.

<comment><USER7> It's their entire business model as well.

<comment><USER8> JWZ suggests:

 _"How will this software get my users laid"_ should be on the minds of anyone writing social software (and these days, almost all software is social software). "Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

<http://www.jwz.org/doc/groupware.html>

<comment><USER9> This coming from a single person that owns a bar.

There are lots of other types in the world. Married, with children, etc.

</comment></comment></comment></comment><comment><USER10> Anyone know of a more automated system to handle forward/backward compatibility? Obviously, there's a lot of manual coding work that has to be done but is there a system that categorizes these various changes (schema or new URL for a page or change in backend service interface), automatically tracks and gets rid of these dependencies after a certain period of time? To give a concrete example, let's say I switched the Facebook messages URL to "/mail" from "/messages". I would mark the old handler as deprecated and eventually, after the new changes have been pushed to everyone, the system will prompt the developer to get rid of essentially the dead code. This is a very simplified example but I believe such deprecation tracking would be useful for more complex changes too.

</comment><comment><USER11> I just wanted to mention one thing about this video. It's missing the first 3 minutes or so where I introduce myself and my team. It's also missing the part where I gave credit for some of these slides to John Allspaw and Paul Hammond from flickr who gave an awesome talk at the 2009 O'Reilly Velocity Conference. Their talk inspired me to put together this presentation.

</comment><comment><USER12> So facebook is programed in PHP but everything on the server is in C++ thanks to "hiphop"? mind=blown

<comment><USER13> PHP is actually one of the slowest mainstream interpreted languages. At Facebook levels of scale, that becomes a serious problem.

<comment><USER14> It doesn't even take a billion hits. I'd say it's a problem as soon as you scale to a couple dozen servers. At that point you're wasting enough money running extra cores that you could have hired another dev instead. We picked up something like 6x web frontend performance by doing a pretty straightforward if tedious Java port (64-bit Sun JVM), and it also put us in a position to start using NIO (with Netty) much more heavily.

<comment><USER13> Interesting, thanks. I don't have experience running PHP apps beyond a few servers, and the database was always the bottleneck.

</comment></comment></comment></comment><comment><USER15> What he says at the beginning is to me the most important. Having great tool is great (!), but the most important is to have the right culture about QA and releases.

</comment><comment><USER16> It's interesting that their entire release architecture seems to be focused on never pushing bad things out to production, whereas given their traffic they could probably push things out much sooner (minutes after they're committed) to small parts of their overall traffic, and slowly increase the traffic on those pieces of code as they prove themselves to be stable, or quickly revert them if they're not.

That would mean having a lot of versions of Facebook live at any one point, but as those parts prove themselves stable they'd gradually be rolled out to all of their traffic.

One point that also wasn't covered is that as they're pushing things out they'll only cherry-pick parts of their codebase depending on which engineers they have around. I wonder if they have a lot of hairy merge conflicts around release time due to that, and bugs in production resulting purely from those merge conflicts. Or worse, subtle bugs resulting in change A going out, but being programmed against a function that was changed in change B, which is not going out because the author of change B isn't in today.

<comment><USER17> _"they could probably push things out much sooner (minutes after they're committed) to small parts of their overall traffic, and slowly increase the traffic on those pieces of code as they prove themselves to be stable, or quickly revert them if they're not."_

The risk to user data is way too high.

This could have serious consequences. You could push client bugs with erroneous API calls, or server-side bugs that cause data loss. Rolling back isn't enough to fix the damage. The user's data has reached a permanent bad state that they didn't intentionally reach. You could roll back the data of every person who used the change, which would undo all of their work. You could analyze the data and try to fix it. This might work, or it might get the user data into a different bad state.

Plus, bugs in the view of the site might not cause errors that pop up in your error console, since it's hard to write tests for "looks wrong." Obvious errors - "when I click on my profile picture my name disappears" - are caught by external people instead of internal people, which adds a level of indirection between a problem appearing and a fix being written.

That being said, there are great uses for gradual rollouts. The video mentions that they do this for mature features with Gatekeeper - the developer can conditionally enable a Prod feature, and see what it does.

<comment><USER18> This is correct, especially for a company under the level of government privacy scrutiny as Facebook. An erroneous push that exposes private user data could lead to a _very_ heavy fine.

</comment></comment></comment><comment><USER19> Anyone know the URL for the code review tool they said they use and open sourced? He said "fabrication", however I cannot seem to find it. It's also not listed in <http://developers.facebook.com/opensource/>

<comment><USER20> <http://phabricator.org/>

</comment></comment><comment><USER21> This is how I push updates for now:

        git pull
        lein uberjar
        sudo restart myprj

<comment><USER22> I like

        git push web

<http://toroid.org/ams/git-website-howto>

<comment><USER23> Fabric is a nice tool for automating deployments: <http://docs.fabfile.org/en/1.0.1/index.html>

For example:

        fab production deploy

or:

        fab web-servers deploy
        fab database backup

.. etc.

</comment></comment></comment><comment> brown9-2 Does anyone know if a non-video summary or set of slides for this video exists?

<comment><USER10> Hacker Newser rasmus4200 took notes here: [http://agilewarrior.wordpress.com/2011/05/28/how-facebook- pu...](http://agilewarrior.wordpress.com/2011/05/28/how-facebook-pushes-new- code-live/)

</comment></comment><comment><USER24> Was able to download this video with savevideo.me

<comment><USER25> This actually wound up being a helpful comment. After switching to HD in order to see his text examples more clearly, I found out that the session starts over from the beginning and _you can't fast forward the video_ at all.

This meant that I had to either stop watching halfway through so that I didn't have to sit through the same half-hour again, or rip the video so that I can watch it like a human.

<comment><USER26> i fast forwarded with no problem. just click to where i wanted to start watching in the video.

not HD mode. stable chrome for mac 10.6.

</comment></comment></comment><comment><USER27> So they don't really test the code, they just push it out, and fix the bugs on Thursdays. Genius strategy. No wonder their platform breaks so often.

<comment><USER28> The code is tested. There are unit tests, Watir tests, tests written by the developer for that specific change, and all changes require a test plan from the engineer.

<comment><USER29> We prefer the term "watirboarding".</comment></comment></comment>


Trump Wants to Keep Parts of ACA: Pre-Existing Conditions and Coverage to Age 27 - <AUTHOR> http://www.wsj.com/articles/donald-trump-willing-to-keep-parts-of-health-law-1478895339 <comment><USER2> A major problem is that Congress mandated the medical ration between young adults and the elderly to be 1:3 instead of 1:6 which better reflects the true costs of care meaning the young would be paying 75% more than they should for their age category. Many have complained that young, healthy people are not signing up for health plans but this is the reason why. The youth are paying 75% more than they should in an efficient market. Fix the medical ratio to be 1:6 and there will probably be a lot more healthy young people signing up for insurance.

Much of the health care costs of the elderly are from chronic disease which itself is from smoking and obesity among other causes.

Other countries such as the UK, France, and Canada have tobacco taxes at least $5 to $7 per pack. The high cost of tobacco has more than half the effect to help people to quit and helps to ensure the young never start smoking. The tobacco taxes can also be used to pay for the higher health care costs that smokers have thus helping to reduce the subsidy in health care that non- smokers pays for smokers.

When the ACA was put into place, they should have raised the Federal tobacco tax to be $5 to $7 per pack (today it is about $1).

<comment><USER3> Although there are plenty of studies to suggest otherwise, at least one study: [http://journals.plos.org/plosmedicine/article?id=10.1371/jou...](http://journals.plos.org/plosmedicine/article?id=10.1371/journal.pmed.0050029) suggests that smokers have a lifetime healthcare cost that is lower for the simple reason that they die earlier, and dying is cheap.

full disclosure: I smoke, and am thus not impartial when it comes to higher cigarette taxes.

<comment><USER2> Very sorry you're a smoker. Even if one is a smoker, one should want tobacco taxes to increase because 1) it is the single best intervention to help others to quit and for youth to never start and 2) today there are negative externalities for government (employees, Medicaid, Medicare, VA, Army) and firms that hire smokers because the health insurance costs are higher than normal. That means tax money that should be going towards other things are going towards tobacco related healthcare Instead. Taxing tobacco ensures that there is not so much of a subsidy of non-smokers for smokers.

Whether overall there is health savings for smokers, while the smokers are being covered by insurance they cost substantially more money than non- smokers.

</comment></comment></comment><comment><USER4> Anyone that looked at his campaign site would have known that he was going to keep parts of it. Instead we have scare tactic headlines all over Facebook about how he's just going to terminate medical coverage for 20 million people.

<comment><USER5> but then his "extremist site" would have been in their browser history

Even in the debates it was obvious both candidates were talking about keeping the act. I thought it was bizarre they didn't acknowledge that to each other.

"Fix it"

"Repeal it and replace it with more competitive state exchanges" so like fix it?

<comment><USER2> The solution is to address the health problems structurally -- it is not going to be addressed by competitive health insurance marketplaces.

Rather, most of health care costs are from chronic disease from mostly tobacco use and obesity. Obesity is largely caused by sugar sweetened beverages (SSBs). Taxing tobacco and SSBs will dramatically reduce the chronic disease costs from smoking and obesity.

</comment></comment></comment><comment><USER6> I hope he challenges Republicans and tells them they can create something better than ACA/Obamacare. Get them on board with that. Then challenge them to send him something better than ACA that genuinely takes care of people. Replace ACA - don't gut it without replacement. If he can do this it could humanize him, the Republican party and do the country good. The problem is 'social' and Republicans don't go together... but perhaps Trump is not all that Republican. Perhaps we need an egomaniac to get things moving. Fuelled by the party hate to get anything Obama related erased.

I know, I ask and hope too much.

<comment><USER7> Yeah, good luck with that. So far, it looks like it's going to be W.'s third term, in practice. But with more racism, xenophobia, and general gloom.

</comment></comment><comment><USER8> Everyone knows what the solution is. One way or another, the Feds need to provide broader subsidies and some form of reinsurance to the ACA market, the same way they already do to the medicaid market via those states who have expanded medicaid. The question isn't what do to, but rather who pays for it, and how. Since the Republicans are historically the party of fiscal constraint, Trump should have much more flexibility to deficit spend than a Democratic President would have. The debt to GDP % will likely increase but we have a couple decades before we find out if that matters or not.</comment>


I've built Rebot.me to help you create a chatbot. Would love feedback - <AUTHOR> <comment><USER2> If it meets the guidelines, this might make a good "Show HN". Curious if the software is open source.

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


Ask HN: Asymmetric Encryption - <AUTHOR> On this page (https://support.microsoft.com/en-us/kb/246071) Microsoft states that:

    Any message that is encrypted by using the private key can only be decrypted by using the matching public key.

 Is that right? I always though, using `gpg` as a base, the messages are encrypting using public keys, and decrypted using the corresponding private key. What am I missing? <comment><USER2> It works in both directions, but the purpose is different.

To put it simply:

Since you are supposed to be the _sole_ owner of your _private_ key, using it to encrypt something allows the public to verify your identity.

<comment><AUTHOR> And that is how signatures work. But while encrypting only, does it still remains the same?

<comment><USER2> Sorry, I'm not sure I've understood your question.

Do you mean _encrypting the same way we encrypt using public key_?

If so:

No, because as far as I can tell, when you "encrypt" a message with your public key you are in fact encrypting a random symmetric key which has been used in turn to encrypt the message. (Both ciphertexts must be sent to the recipient.)

As you may infer, if we use the same mechanism but encrypt using the private key, we just cannot ensure the authenticity of the message.

Edit: corrected typos.</comment></comment></comment>


Less is exponentially more (2012) - <AUTHOR> https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html <comment><USER2> > Early in the rollout of Go I was told by someone that he could not imagine > working in a language without generic types. As I have reported elsewhere, I > found that an odd remark.

> ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']...

> If C++ and Java are about type hierarchies and the taxonomy of types, Go is > about composition.

How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles!

(And then as a minor concession to programming usability, he adds generics anyway, but _only_ for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)

<comment><USER3> I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy.

But that has nothing to do with having an expressive type system and generics.

We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.

</comment></comment><comment><USER4> A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough.

Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-assed language. I dumped it, tried rust, and even with its slow compile times I couldn't be happier.

Now a few releases later, they fixed sort so I can only implement compare. Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A is source code generation, a clear indication go isn't enough on its own. I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again.

It was a near miss, though. SOme things are clearly correct. I want to look again when they finally have generics, and some basic collections. I hope that day comes and I can give it a new chance. But until then, less was simply not enough .

<comment><USER5> It's interesting the things that people think are essential and the things they are willing to put up with. I'm willing to put up with writing my own sort.Interface, adding in a few lines of boilerplate for error handling, loops, and the odd linked-list/btree/etc. I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc. I'm willing but _very_ reluctant to use a language that requires me to write a bunch of scripts to automate publishing source code and documentation packages. I'm willing but very reluctant to use a language with minutes-long build times. I'm willing but very reluctant to use a language that where most packages are poorly documented, lacking even basic type information (looking at you, Python and JS). I'm willing but very reluctant to use a language in which the ecosystem is an absolute mess due to the pervasive use of inheritance. I'm unwilling to use a language that simply can't be optimized (and "just write it in C" or "just use multiprocessing" are only applicable to a narrow range of bottlenecks--good luck processing a large Python data structure, for example).

This isn't Go fanboyism; I've worked with lots of languages in my career, and I still get really excited and try new languages all the time, but they all tend to optimize for nice-to-have things (such as a type system that can handle those 1-5% of use cases where Go would have you drop to interface{}) in exchange for essential things like sane tooling. Rust stands alone as a possible exception, but only since it shipped non-lexical lifetimes, rust- analyzer, and a long tail of other improvements that have recently brought its usability down into a range that is acceptable for general application development.

<comment><USER6> >I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc.

Ironically, the fact go tried to make me use GitHub as a stopgap package manager (& denied one was necessary) while they built their own was what made me run away screaming.

They've since fixed that but seeing them fail at what Perl managed in 1995 and what became standard is larger languages around the turn of the millenium in a brand new language in 2010 wasn't a great omen.

<comment><USER5> People scoff about "GitHub as a package manager", but it hasn't chafed me much. Moreover, the scoffing isn't very substantial--it's often some variation of "but GitHub goes down all the time?! You will never be able to build/distribute your software!", which is trivially refuted (the GitHub UI goes down all the time, but its git service going down is much rarer; you can use a caching proxy if you're really concerned about reliability of the git service just like you would with a more typical package repo; GitHub isn't necessary to distribute Go applications unlike Pypi/NPM/etc for Python/JS apps). There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing and I haven't stumbled on them (e.g., I don't have any private repo dependencies for my projects, but perhaps it would be a PITA for those who do?).

<comment><USER6> >it's often some variation of "but GitHub goes down all the time?!

It was never about github's downtime. It was about having to manage the code of your dependencies yourself.

>you can use a caching proxy if you're really concerned about reliability

yay one more piece of infrastructure that will break.

>There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing

I really think they were.

</comment></comment></comment></comment></comment><comment><USER7> While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.

<comment><USER8> I feel the same, we are starting to use Go now and I really don't like it.

Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go.

And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.

There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go.

I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.

<comment><USER9> > And I find it pretty unreadable, it's not nearly as expressive as other > languages I enjoy using.

I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features.

If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.

<comment><USER10> The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up time of people who already know how to write straight-line code and jumps.

<comment><USER7> Yeah, I think the charge of "clever" is often thrown out when one uses a different way of thinking. I'm not an FP zealot at all, but I do think learning to think recursively does something to one's programming. (Working through SICP or even The Little Schemer) My own personal take it that I appreciated and enjoyed some of those paradigms far more. What I would NEVER try to do is turn Java or Go into those paradigms though. I would, however, like to have some of those handy niceties available by default. (I want to map over a collection and apply a function to each member). But again, that's a personal preference.

<comment><USER10> It is idiomatic in Java to use the streams api for mapping, filtering, and reducing. It is a perfectly natural fit in the language. The only bummer is that those operations can't be built directly into the collections api due to compatibility concerns. It doesn't require thinking recursively or anything clever or advanced, they are very simple operations.

</comment></comment></comment></comment></comment></comment><comment><USER11> Pike's take is pretty unfair to C++11, given how ideas like 'rvalue references' held up REALLY well.

Yes, they were introducing even more complexity to a complex language, but how else are they supposed to incorporate better ways of doing things while maintaining backwards compatibility?

I suppose one could always just build a new language that doesn't have the historical cruft, but in this case that's Rust and not Go.

</comment><comment><USER12> >Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive.

Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?

<comment><USER13> To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class- based" languages, not anything to do with types in general.

<comment><USER14> > To be honest programmers have a habit of being very loose with language.

I wish this weren't true. It's quite damning.

It's less bad in a real-time conversation, with fast feedback about how well we're being understood. But it still hints that we don't have the concepts clear in our own minds.

</comment></comment></comment><comment><USER15> Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.

<comment><USER16> > _I wish the error-handling looked more like Rust 's Result type instead of > the double-return idiom._

After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.

<comment><USER17> Swift is nice but I don't see it making much sense outside of the Apple ecosystem.

<comment><USER18> It's a wonderful language. I'd love to work with it server side it I found said job.

</comment></comment></comment></comment><comment><USER19> For any new language that I learn, my go-to thing to try is to implement 4th- order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language.

* C++, easily doable with templates.

* Python, easily doable with duck typing.

* Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input.

* Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply()

* Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading.

Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.

</comment><comment><USER20> _" People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more."_

I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.

</comment><comment><USER21> > What you're given is a set of powerful but easy to understand, easy to use > building blocks from which you can assemble—compose—a solution to your > problem. It might not end up quite as fast or as sophisticated or as > ideologically motivated as the solution you'd write in some of those other > languages, but it'll almost certainly be easier to write, easier to read, > easier to understand, easier to maintain, and maybe safer.

I really like go, and I daresay it makes many things easy to implement and understand, but I do find the flexibility/lack of sophistication allows one to end up writing what amounts to improved C. Great for smaller projects, but surprisingly difficult to manage as it grows.

</comment><comment><USER22> Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.

<comment><USER23> OK, but for Go to succeed in that environment, it had to be _better_ than Python and Java at programming for the cloud. It doesn't matter that Python and Java were "aging" \- programming languages don't die from old age. Go had to be better than what was there.

And in what ways was it better? Power and simplicity (at least for writing those kinds of programs).

<comment><USER24> Why did it have to be better? It just had to be created and evangelized to a specific group (and likely because it was by a specific company). I don't think it has anything to do with "better" in one way or the other.

Developers are constantly looking for new languages to fiddle with without any objective reasoning.

<comment><USER23> Sure, they're looking for new languages to play with. They're not looking for new languages to write major projects in, though. You write major projects in languages that you have already fiddled in, and the fiddling has given you confidence that they're up to the task. Nobody (sane) sees a publicity blurb and decides to bet a major project on it.

Don't confuse "they came to a different conclusion than me" with "they're sheep".

<comment><USER24> I mean cargo culting tech and languages is practically a meme at this point in tech. I'm not sure I can scientifically argue that its widespread but I think it is equally futile to argue that it does not happen frequently.

<comment><USER23> Does it happen? Sure. More often than it should? Absolutely.

Often enough to account for the popularity of Go? I strongly doubt it. It could have accounted for Go's popularity in the first year or two. But now, Go has been used by too many people to do too many things. Go's popularity now is based on its ability to help you get things done, not on Google's name.

</comment></comment></comment></comment></comment></comment><comment><USER25> This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive.

For example, in Java one can trivially create a class like `Maybe<T>` with a method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.

</comment><comment><USER26> I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary.

[https://github.com/protocolbuffers/protobuf- go/blob/master/i...](https://github.com/protocolbuffers/protobuf- go/blob/master/internal/pragma/pragma.go#L29)

Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.

</comment><comment><USER27> I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language.

I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not).

IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.

<comment><USER28> Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They _prefer_ explicit and awkward concurrency constructs, perhaps because until Go, mainstream languages like JavaScript, C#, and Python implemented hacks largely because of implementation constraints, so it's all they know. They say thinks like, "I prefer knowing exactly when I might block". Yet you never hear them bemoan the fact that the OS hides process scheduling and VM paging; they don't complain that they can't hook into this at all, let alone be forced to do it 100% of the time for even the simplest code. They never ask that their language _force_ them to be explicit about how and when a simple function call will setup a new stack frame. All of these things were, decades ago, the equivalent of fibers (or more generically asymmetric stackful coroutines). People were likewise skeptical about those things, but today these innovations--function calls, preemptive scheduling, virtual memory--are ubiquitous and invisible and the notion of doing away with them completely or even as default semantics, for all basic programming, would be inconceivable. What small cost they impose upfront by being the default (and often only) construct is vastly outweighed by their power; they're undeniably the correct way to model the vast majority of computing problems at the level with which they're concerned.

I agree, goroutines (or perhaps something a little more generic that doesn't conflate stack reification with scheduling) are absolutely the correct abstraction, and this will be proven in a few decades time. But until then we're stuck with people rationalizing the limitations of async constructs in their favorite languages; constructs primarily chosen because of quirky design constraints, principally C interop and C-based VM implementations that leak the semantics of the C ABI stack.

<comment><USER29> Java is going a similar route (project Loom), but they'll be implemented in a better way. Things like timeouts in golang are awkard to enforce, and monitoring hierarchies are not built-in. Java's Loom is already getting both.

<comment><USER30> Getting getting getting, every time I head about how Golang is spanking other languages I see the "BUT MUH JAVA IS GETTING X IN Y $MONTHS".

If you really can predict the future please tell me lotto numbers rather than being abrasive.

<comment><USER29> The irony is that golang was created to replace C++ at Google, yet it didn't even make a dent in its usage for serious products. C++ and Java remain the heavy lifters there, as well as at other major establishments, precisely because of reasons like performance and (on the JVM) monitoring. golang ended up being more of a Python replacement.

<comment><USER28> Go was never intended to replace C++. It was aimed at a very specific target: engineers, especially junior engineers, writing function-as-a-service software. Thread-based concurrency (as in logical thread of execution, not "kernel threads") with message-based synchronization, structural typing, and static compilation were their answers to what in their experience were the biggest impediments to writing good network software that could scale reasonably well using the most natural programming approach.

All of the original creators were clearly of the "best tool for the job, even if you have to build it from scratch" persuasion. How many different languages and programming constructs can you find on Unix or Plan 9? The notion of centralizing all development around a single all-purpose language, a la C++ or Java, is anathema to their stated engineering principles and the opposite of the design elements of the many computing environments they spent their careers designing and using.

One can quite easily disagree with their design choices and tradeoffs. I find static compilation short-sighted. But I do appreciate how it fits into their overall approach; and in that way I find static compilation _less_ short- sighted in Go than in Rust. Some aspects of goroutines are problematic. Hassles with dealing with timeouts exposed flaws in their scheduling and message passing abstractions. But those flaws are in the details, not the fundamental model; and the better way to implement those details is more difficult to determine. (I've had to wrestle with such questions myself as I've written multiple async I/O libraries and frameworks. If Go had come out 10 years earlier my entire career trajectory may have been different.)

FWIW, I don't write any Go software. I admire it from a distance, the same way I admire C++, Rust, and Java[1], while I slave away in C and several other languages. Though, there's an honesty and clarity in Go that is lacking in other languages, precisely because Go _isn 't_ trying to be an all-purpose language, and because the authors have an understanding of (and deliberately leverage) the interplay between design goals and implementation constraints that can only come with having designed and implemented umpteen different languages before.

[1] I did have a short tryst with Java a long time ago, but it actually ended up driving me into the arms of C. Not because of the language, but because of the ecosystem--licensing, tooling, interop, etc, was an extremely poor fit for Linux, and in many ways still is.

<comment><USER29> > Go was never intended to replace C++

As per the creators of the language who claimed that they got the idea of writing a new language while waiting for C++ to compile, it was. You can read up about this from them, they were quite clear about it. They even expressed surprise as to why they didn't get the migration of C++ programmers they were anticipating to golang, but instead got Python programmers.

It's not like the lack of green threads stopped people from writing highly concurrent code. Libraries like Vertx, Reactivex, and Akka have existed for a while now. Also, all major platforms have a notion of green threads/coroutines (Java is getting the former and C++ is getting the latter). This was practically the only thing golang had going for it, and once they're implemented for those platforms, it's hard to make a case for golang given it's bad design decisions.

> Hassles with dealing with timeouts exposed flaws in their scheduling and > message passing abstractions.

That's a good point, which is why Java's green thread implementation is superior to golang's. Timeouts and cancellations are designed in from the start, as well as hierarchies of green threads (similar to Erlang's).

Again, it just show's that golang does the minimum, and pushes complexity onto the user under the guise of simple language design.

> licensing, tooling, interop, etc, was an extremely poor fit for Linux, and > in many ways still is.

The JVM is open source and has been for a while now. Could you elaborate on why it's not a good fit for Linux?

<comment><USER30> > That's a good point, which is why Java's green thread implementation is > superior to golang's.

So the future invention of something that doesnt currently exist is going to be better than something that does exist is your argument?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> I code in Javascript/Node, and I also code in Go. They're both very useful tools and they're useful in different ways. I find Go to be a good tool when I know what I'm writing and I have clear forms in each step.

</comment><comment><USER32> Previous discussion since the HN "past" link doesn't bring up the prior thread because tld was ".de" instead of ".com" : [https://news.ycombinator.com/item?id=6417319](https://news.ycombinator.com/item?id=6417319)

</comment><comment><USER33> I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world --in-house hosted and cloud.

I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity.

IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go.

The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You.

The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory.

Because of go fmt, _all_ Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects.

I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing.

So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib.

And most of all we get a platform that understands and managed complexity in a favorable way.

$0.02. Ok, maybe $0.05 (inflation).

<comment><USER34> > I abhor the Java ecosystem for so many reasons I just don't have the energy > to go into.

If you can gather some energy, I'd be interested in that.

<comment><USER33> Like I said there's nothing wrong with the stack. I was ONLY speaking of my personal preferences why I choose not to Java when I can Go: Just personal preferences.

\-- Compile times!

\-- Operational complexity vs. Go.

\-- Built-in tooling vs. Go.

\-- Verbose XML configuration files.

\-- Lots of libs favor XML vice JSON.

\-- Deeply-nested code directories.

\-- Class-centric model (only).

\-- Verbosity and boilerplate.

\-- Factories of factories of factories. :)

\-- JVM install and config (many dials = control but also complexity).

\-- Impractical / painful to write without an IDE.

\-- Concurrency model, as compared to Go.

\-- Std lib not matched to work I use Go for.

\-- Memory consumption.

\-- Performance (for the work I do).

\-- Multiple inheritance (allows unnecessary complexity).

\-- [https://astaxie.gitbooks.io/build-web-application-with- golan...](https://astaxie.gitbooks.io/build-web-application-with- golang/en/03.2.html) vs. [https://medium.com/@ssaurel/create-a-simple-http- web-server-...](https://medium.com/@ssaurel/create-a-simple-http-web-server- in-java-3fc12b29d5fd)

\-- Oracle.

(edits: reformat pretty; compile times)

<comment><USER29> > \-- Compile times!

golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file.

> \-- Operational complexity vs. Go.

The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.

> \-- Verbose XML configuration files. > \-- Lots of libs favor XML vice JSON. > > \-- Factories of factories of factories. :)

Nothing to do with the language.

> \-- Deeply-nested code directories.

I've seen the same in golang code due to its packaging.

> \-- Verbosity and boilerplate.

golang is more verbose and error prone for any non-trivial code base

> \-- JVM install and config (many dials = control but also complexity).

The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM.

> \-- Concurrency model, as compared to Go.

Java is getting green threads (see project Loom), and they'll be superior to what golang offers.

> \-- Impractical / painful to write without an IDE.

Irrelevant for any non-trivial code base, since golang needs and IDE as well.

> \-- Std lib not matched to work I use Go for.

let's see what golang has to offer anything remotely similar to java.util.concurrent.*

> \-- Memory consumption.

Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more.

> \-- Performance (for the work I do).

They're on par, and for any non-trivial code base, Java tends to be faster.

> \-- Multiple inheritance (allows unnecessary complexity).

Java doesn't support multiple inheritance.

<comment><USER30> Reading this, it honestly looks like you don't know how to write Golang and wish you could write more Java.

That's fine but pretending you're an SME and throwing off false equivalencies is really dishonest.

<comment><USER29> I know how to write golang, which is why I'm well aware of its shortcomings and the issues its inferior design causes, and the costly bandaids that have to be implemented to poorly attempt to mitigate said issues.

<comment><USER30> Got an example repo you've worked on as happy to help work with the ecosystem rather than against it?

<comment><USER29> It's a non-public code base.

<comment><USER30> So a single project, that you designed and built is causing you problems?

I don't think Go is the problem

<comment><USER29> It's a huge code base, with literally thousands of sub-projects, with non- overlapping teams working on them. When I see the same issues arise, the only common thing is the language.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project?

The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now

</comment><comment><USER36> See also:

[https://news.ycombinator.com/item?id=16548684](https://news.ycombinator.com/item?id=16548684) (2018)

[https://news.ycombinator.com/item?id=6417319](https://news.ycombinator.com/item?id=6417319) (2013)

Discussed at the time: [https://news.ycombinator.com/item?id=4158865](https://news.ycombinator.com/item?id=4158865)

</comment><comment><USER37> Needs "(2012)" in the title.

</comment><comment><USER38> Please tag this with the date, 2012. Great but old blog post.</comment>


Basically flawed - <AUTHOR> http://www.economist.com/news/leaders/21699907-proponents-basic-income-underestimate-how-disruptive-it-would-be-basically-flawed?cid1=cust/ednew/t/bl/n/2016062n/owned/n/n/nwl/n/n/E/n <comment><USER2> It seems like a lot of the people who understand technology agree that some form of UBI, sooner or later, is a given. On the other hand, a lot of the people who don't understand technology, disagree that it's a given.

I think it's a given because technology reduces the need for labor in that it allows fewer people to provide for the same needs. If we continue to rely on "work as the main mechanism which allocates spending power" we'll run into a huge problem when only a few people are "working."

If we just plain don't need everybody to work in order to provide for everybody's needs...then we'll need a way OTHER THAN work to distribute the stuff everybody needs. We'll either invent activities that aren't actually work (like Japan assigning people to open doors) or we'll give people what they need without asking them to work for it.

People who grok technology seem to agree on this conclusion even if they don't arrive at it in quite the same way.

</comment><comment><USER3> I have an alternative proposal that almost gets to a guaranteed basic income (GBI) over time, but with less disruption along the way. I call it guaranteed basic goods (GBG).

The idea is that instead of the government giving money directly to people (GBI), the government pays to research, develop, and implement automation of the production of goods. The goal for each given good is to set up a production and distribution chain that has very little human involvement, and is publicly owned, with the output being given away to the public.

So, over time, good by good, things move from the market economy, where you have to have a source of money in order to get them, to the public economy, where they are produced publicly and you have a share of the output. For instance, take food. There are several crops now whose production is largely automated, with planting, fertilizing, watering, harvesting, and packaging done by machine. We are at most a couple of decades away from automating much of the distribution from farm to city.

Within 30 years we could have publicly owned mostly automated production and distribution of sufficient food crops so that every citizen's share would be enough to live well from.

Aside from housing, I see no reason that we cannot, within 40 years, have a sufficient variety of goods produced this way that those who wish to can live comfortably entirely on their share of the publicly owned factory and farm output.

There will still be tasks that cannot be automated (at least for a very long time), and so there will be a path for those who want more than is provided by the public output to earn money to buy those things only available in the market economy.

The automation will happen, getting rid of large classes of jobs completely and in many others making it so 1 human can do what formerly required dozens. The number of jobs created designing and maintaining the machines won't be anywhere near the number eliminated, so we are going to have to find some way to cope with very large unemployment.

</comment><comment><USER4> Extremely short-sighted article.

</comment><comment><USER5> Rothschild and [https://en.wikipedia.org/wiki/Dominant_minority](https://en.wikipedia.org/wiki/Dominant_minority) will definitely oppose UBI

</comment><comment><USER6> > WORK is […] is the main mechanism through which spending power is allocated.

Is it now.</comment>


CDNJS: The Fastest Javascript Repo on the Web - <AUTHOR> http://blog.cloudflare.com/cdnjs-the-fastest-javascript-repo-on-the-web <comment><USER2> Low latency with a handful of pingdom monitoring nodes sitting in data centers does not necessarily translate to the "fastest repo on the web". We've tested CloudFlare since their launch using thousands of real users, and based on that testing performance tends to be on the low end compared to traditional static content CDNs. CloudFlare is more of a website proxy than CDN. By assuming full control of your website DNS, it stands out more with add-on features like security. Here is a link to some real user performance analysis I've compiled for various CDNs including CloudFlare: <http://dl.dropbox.com/u/20765204/feb12-cdn-report/index.html>

<comment><USER3> I have similar experience with CloudFlare. The Speed just isn't there. Most CDN perform MUCH better then them. I would love to pay to even get faster speed. But that is not the model they decided to work on. I hope they will have more speed improvement coming in soon.

</comment></comment><comment><USER4> this shouldn't be hosted on the cloudflare.com domain. since I am a customer every request sends my cloudflare session cookie and a bunch of Google Analytics cookies.

Not only is it 2.5KB of extra header info sent, but I don't think cloudflare should know which websites their customers have been visiting.

<comment><USER5> Yeah, that is an odd decision. Makes you wonder if the "secret" motive of CloudFlare in hosting this, other than to promote their service, is to track and analyze your visitors.

I don't see a privacy policy on CDNJS.com. I'd definitely like to know what data they collect about my visitors and what they do with it.

At least the CDN doesn't itself _set_ any cookies.

<comment><USER6> If anything this would only work on other cloudflare users (like people who logged in to cloudflare). Most users won't have any cookies on that domain.

<comment><USER7> There's nothing to stop them setting cookies in the responses down the track though. Wait until you've got enough users, then one day just switch on your 3rd party multi-site user tracking. Or perhaps less publicly dicoverable, use browser fingerprinting and ip address correlation to do the same thing with somewhat less accuracy, but completely invisibly.

And note too, that if you're relying on a 3rd party to serve javascript your users are going to run in their browsers - if that 3rd party isn't trustworthy, you're screwed in much worse ways that cookie tracking privacy violations. Who'd notice if they started occasionally serving a modified version of jQuery which sent all form field keydowns (aka, your usernames and passwords) back to theselves?

<comment><USER6> Following the money will especially help in this situation.

How does CloudFlare make its money? It's a CDN company. I mean, that's the CORE of what they do. What is jsCDN? It's a CDN.

A simpler theory is that hosting a Javascript CDN (and demonstrating that it's even better than Google's, which is amazing), is going to provide a lot of free advertising for their product. If I use their CDN for JS and it works really well, I'm likely to go back to them for hosting other things, because using jsCDN is almost like doing a free trial of their actual CDN.

It's not even like their main form of income is in another industry that we have to make a cognitive leap to see what their ulterior motives are. It's precisely this. CDNs.

</comment></comment></comment></comment></comment><comment><USER8> For analytics and tag generation of libraries hosted by CDNJS, take a look at: <http://www.scriptselect.com> It's a weekend project I did a couple of weeks ago using d3 and backbone. You can select libraries, view selected library size, and copy the generated script tags for the libraries you've selected. Just a little tool to make using CDNJS a little more convenient. If there's enough demand, I'll add other CDNs.

Thanks to Ryan, Thomas, and CloudFlare for a very cool service!

</comment><comment><USER9> Quick question... I thought the best part of CDN hosted js files was that they were more likely already cached on the client, not so much for the speed of delivery.

So, wouldn't it be better to go with the most popular and not the fastest?

<comment><USER5> For jQuery, maybe. But if you're using, say, Backbone, that point is moot because only CDNJS has it. The Google CDN[1] only hosts 11 libraries, CDNJS hosts over 200.

1\. <https://developers.google.com/speed/libraries/devguide>

</comment></comment><comment><USER10> +1 to joshfraser - cache hits always beat requests. I remember seeing a stat about n% of top 100 sites use the google CDN for jquery, it was by far the most popular. Stick with Google for popular libraries.

</comment><comment><USER11> Backing up wild performance-claims with a _Pingdom chart_?

I really don't know how anyone can take CloudFlare seriously anymore...

</comment><comment><USER12> They say this is 'peer-reviewed' but is that all? If someone sends them a pull request for an update to a widely used but perhaps smaller library, will they review it or does it just get merged into the CDN? It seems like a good way to get access to millions of browser sessions. Is anyone in Cloudfare taking responsibility for checking that the code is coming from the authoritative repo and not joeblow/underscore.js?

<https://github.com/cdnjs/cdnjs#pull-requests-steps>

While Google and Microsoft are slower to update their libs, we can assume that they are downloading releases from official sources.

<comment><USER13> Contributors generally include the links to the official sources.

If not we track down the official repositories ourselves.

Once we have verified the source, we then check the diff against the submitted and official. We have always flirted with the idea of a level of automation to handle this. But your comment addresses the problem with a solution such as that so we are still manually diff checking for maximum security.

</comment></comment><comment><USER14> The fastest request is the one that never happens. One of the biggest benefits of using hosted libraries is that browsers cache those files locally. By sharing the same URL for your copy of jQuery with thousands of other sites, you increase your odds of getting a local browser cache hit. For popular libraries like jQuery you're probably best using Google since they have the most adoption. That said, I think CloudFlare's CDN is an interesting idea and could grow into something genuinely useful especially for less popular libraries.

</comment><comment><USER15> The question I have [but not the answer] is:

Usually in every project there is bunch of .js [jquery, backbone, etc] and .css files. So the good practice is not only to minify and compress, but also to bundle some/all of them into several big combined files to save on extra HTTP calls.

So my question is - what is better - (1) have separate files served from such CDN [or any public CDN] or (2) combine the files and serve yourself by nginx/AWS?

Not a developer, feel free to correct any mistakes :-)

<comment><USER14> It's a great question. The answer depends on a lot of different variables like your cache hit ratio, the size & number of files, etc. I'd recommend doing a performance A/B test using JavaScript to time which one is best for your particular site. We offer a free Real User Measurement tool at Torbit (<http://torbit.com>) that includes the ability to do A/B tests like this.

</comment></comment><comment><USER16> cdnjs is a great public service, I've been using it for various projects for awhile and it seems consistently fast everywhere.

</comment><comment><USER6> I've recently started using CDNJS for my projects. Thanks to Ryan, Thomas, and CloudFlare for this awesome service!

Even happier to see that you guys host CSS and images for the common libs. I will change my bootstrap css hosting over to yours soon.

</comment><comment><USER17> We can still improve this by caching across CDNs.

<comment><USER18> You mean updating browsers to recognize the same file across different domains (e.g. md5 hash, etc)?

<comment><USER17> I mean this... [http://alexchamberlain.co.uk/opinion/2012/09/13/cache- across...](http://alexchamberlain.co.uk/opinion/2012/09/13/cache-across- domains.html)

<comment><USER4> the reason this hasn't been done is:

a) would require all servers and browsers to be updated for what is a marginal gain

b) privacy nightmare

<comment><USER17> a) No it wouldn't; it would be totally optional. b) Get over it; there is no difference between this and CDNs.

<comment><USER4> > Get over it; there is no difference between this and CDNs.

except the part where you track people across sites

what I am saying is not speculative. this has been proposed previously, and shot down. there is a reason why it hasn't happen.

<comment><USER17> Where would you be tracking people across sites?

<comment><USER4> If you trawl through the IETF and more recently WHATWG mailing lists you will find that every time caching comes up - either with Last-Modified or when ETag was being ratified the proposal for cross-origin caching also comes up, and is rejected.

The browser vendors just spent the past 4-5 years locking down cross-origin access in the DOM because of all the security and privacy implications that come up. Corporate profiles and ISO standards don't even accept running the code - let alone caching it (i've worked on plenty of corporate projects where you aren't allowed to even use Google hosted JS - it just won't run due to AD policies).

To give you but one example of what arises with this new vector. Say I were to go to the top 50 banking sites and take a sample of a Javascript file that is unique to each site. I would then take the hash of each file, and in a single web page include the script element with a hash of each of those files. When a visitor hits that page and the browser attempts to load each script element, if it loads it in 4ms then I know the file was in the cache and that the visitor is a customer of that bank.

<comment><USER17> Why would the banks enable hashing on their unique stuff? It would be their security flaw, not the design of the system.

<comment><USER4> Well that is just one, and as I mentioned cross-origin requests and access have been further locked down recently, not opened. With all the different versions and variants of libraries you are implementing and exposing a lot to save very little. You wouldn't even save 1% of web requests. as mentioned, this isn't a new idea, I'm just telling you the reasons why it hasn't and won't happen

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> is the chrome extension[1] working? was just thinking that I might start to use it if there was a browser extension that makes sure those requests stay always local. otherwise its rather slow to use any remote resource while developing a page locally.

<https://github.com/cdnjs/browser-extension></comment>


How Hulu Lost Its Place In a Netflix World - <AUTHOR> http://www.wired.com/epicenter/2011/01/hulu-lost-place-netflix-world/ <comment><USER2> _with the exception of sports and certain "event programs"_

Yeah but that's a hell of a big exception. People are willing to pay a lot of money for those.

My household "cut the cord" [we're Netflix-only, no cable/satellite/OTA] and the only thing we miss are the sports - even if I had to pay $20 to, say, watch an F1 race online, I'd still be way ahead of what I used to pay for cable/satellite, so I would likely pay hulu (or whoever) for it.

<comment><USER3> I'm hardly the one to pay for anything, but I do play for netflix. And at just $15, it's a far far better alternative than paying for cable. I get to watch anything, at any time that I want? It's the way TV should be nowadays.

the only downside is that netflix recommendations don't work too well for me. Too often, I spend more time picking what to watch, rather than just watching something.

<comment><USER4> The other downside is you only get 2 channel audio.

<comment><USER5> 5.1 on the ps3: [http://www.engadget.com/2010/10/14/netflix-on-ps3-goes- disc-...](http://www.engadget.com/2010/10/14/netflix-on-ps3-goes-disc-free- gets-1080i-streaming-and-5-1-surr/)

<comment><USER4> Brilliant! (I just wish it was easier to tell which ones were in 5.1.)

</comment></comment></comment></comment></comment><comment><USER6> I'd like to see this statement sourced...

 _And studios, despite some hemming and hawing, would ultimately rather make a lucrative — reportedly up to $100,000 per mid-season episode — deal with Netflix than rely on middling ad revenue on Hulu._

$100,000 isn't that much. Put it this way. The show Two and a Half Men pays its three stars a combined $3.2 million per episode. Another example is Big Bang Theory which just made a deal for 3 more seasons in which the network will pay $4 million per episode (and is probably making way more)

CABLE pays around $2 million per episode to syndicate the very shows Netflix is offering $100,000 for (<http://tinyurl.com/48c5zo9>)

So $100,000 an episode is more a joke than a real offer that Hollywood is seriously considering.

<comment><USER7> This article (previously featured on HN) mentioned that Netflix pays much less than cable: [http://www.hollywoodreporter.com/news/hollywood-execs- privat...](http://www.hollywoodreporter.com/news/hollywood-execs-privately- netflix-71957). I think the point of that statement is that Hulu pays much less than $100,000 per episode.

</comment></comment><comment><USER8> I own four set-top devices that support browsing and viewing Netflix streaming content directly from the device.

I own zero devices that can do the same with Hulu.

This is the #1 reason Netflix gets subscription money from me and Hulu does not.

<comment><USER9> My roku can stream both Hulu Plus (which also costs a subscription fee) and netflix. I tried out hulu plus, but after the first commercial streamed in the middle of my show, i stopped it and stopped watching hulu plus. I'm ok paying for a streaming service, and I'm ok with free content having ads, but not both at the same time.

</comment></comment><comment><USER10> What I love about Netflix streaming is that it completely severs the old TV- viewer relationship of having to worry about "what's on now" and "when does my program start". Since we started using Netflix streaming, we spend a lot more time watching what we want to watch _when_ we want to watch it. Instead of having to worry about having dinner done in time for your favorite program, your favorite program now starts whenever the hell you're ready for it. :-)

I also like that I can start watching a series from the beginning, no matter how long its been on. As an example, my wife and I are currently hooked on the show "Weeds". It's been on for 6 seasons already, so trying to get into it _now_ on cable would be...difficult. But with Netflix we've been able to start watching from the first episode with no problems.

</comment><comment><USER11> Here's where Hulu lost me as a consumer, it was simply the decision to make their premium service provide extra content and mobile features instead of eliminating ads. Netflix wins because it spares me from advertisements. You have no idea how much I'd be willing to pay companies [even on an individual basis] to never see another advertisement of theirs again.

</comment><comment><USER12> I can look at all the streaming content on Netflix and know it'll play on my computer, iOS device, Xbox, TiVo, Roku, whatever.

Hulu, however, has content that is web-only. For example, I can't watch the Simpsons on my phone, only on the web, even though I thought part of the deal with paying for Hulu Plus was having it on other devices. Why pay for being able to watch content on your TV when they don't permit you to watch the popular stuff on anything but a PC?

And given what they did to Google TV users, I know that if it were technically possible for Hulu to identify you were watching on a TV-connected HTPC and block you for it, they probably would.

</comment><comment><USER13> These two companies don't do the same thing under the hood. Netflix has a lot more time to do it's transcoding than Hulu does. Hulu gets their content from studios and has to have a turnaround of hours sometimes, whereas Netflix can take weeks to get something online.

Yes, there's a battle for the livingroom going on, and Netflix could start building out the same infrastructure. But it's not trivial for Netflix to just step in and 'steal' away Hulu's customers without first doing a lot of work to lower their transcoding turn-around.

For now, both companies have their place because they're not providing the exact same service to the studios.

</comment><comment><USER14> I completely get why people love Netflix. But if Hulu can't be a serious competitor, who will be? I don't want Netflix to be my only appealing streaming option, and I don't want to pay cable operators a ton of money for stuff I don't watch.

<comment><USER15> Apple, PlayStation Network, Vudu, etc.

</comment></comment><comment><USER16> I'm waiting for netflix to start cutting deals to stream shows the day after they air, a la Apple. I'd happily subscribe for $20/show to subsidize additional costs on netflix's side.

<comment><USER17> Unless you only watch 3 shows, isn't cable with a DVR a better value?

<comment><USER18> I think it's $20/show per _season_ , whereas cable runs ~$60/month.

<comment><USER17> Oh, duh. Good point.

</comment></comment></comment></comment><comment><USER19> I've been a Netflix customer since 2002. Every time I attempt to use Hulu for anything other than the handful of current TV shows I watch (Fringe, Community, Chuck) I'm woefully disappointed in their offerings.

But more than that I'm frustrated by the UI and search. I don't know if that's why Hulu lost its place in a Netflix world, but it's certainly why its losing its place in mine.

</comment><comment><USER20> It's all been stated before. With Netflix I can watch anything I want whenever I want on whatever device I want with no ads. That's worth paying for. You can't get that with Hulu's limited selection and web-only viewing experience. I don't mind missing out on current episodes because I have hundreds of thousands of other stuff to watch. In the current episode space, Hulu also competes with the networks themselves. ABC, CBS, Comedy Central, etc all have their own streaming video websites.

</comment><comment><USER21> I recently cancelled my netflix (streaming) subscription because the selection isn't very good. Until I can watch the current a-list TV shows and movies, it just seems like a constant compromise not worth making. Instead I watch hulu or other online streaming for TV shows, and rent movies from amazon on demand (much much better selection for recent releases). Then again, I have a mac mini hooked up to my TV so it's no problem watching any internet streaming video on it.

</comment><comment><USER22> As an Ubuntu user in Canada, they've both lost their place in my world. Netflix is here, finally - 12 or 13 years later than the USA - but they don't support Ubuntu. And Hulu's still constrained to < 5% of the world's population.

There's so much room in this space to innovate, with Step 1 being LEAVE THE USA! And Step 2: Use the WEB! Why can't we get rid of these proprietary plugins?

Any company that does both 1 and 2 will be immensely successful.

<comment><USER23> It would probably cost Netflix more to add Linux support (and test it, and continually support/update/test it for the rest of forever) than they would ever make off of it, at this point.

And that's without the cost of advertising that feature.

I have always thought that if you choose to run Linux, you're smart enough to figure out a way to get things to run on Linux that don't officially support it. (What percentage of Linux users know how to program in at least 1 language, vs. what percentage of Windows users? 98% and <0.5%?)

<comment><USER24> Us Linux users are used to using unsupported/"use at your own risk" software, so that definitely lowers costs.

Right now what prevents Netflix from running on Linux is Microsoft. They will license PlayReady DRM but won't license it to run on Desktop Linux boxes, citing some sort of bogus "security" issue. I would think that an XP box would be much less secure than a Linux box. It's just a business decision masquerading as a technical decision.

<http://forums.silverlight.net/forums/t/94992.aspx>

<comment><USER25> It'd be much easier on Linux to tap the video stream from the Silverlight player. You could probably do it in userspace, with a modified X server, or even something like Xnest. The only way I can think of for Silverlight to get around it would be to talk to the GPU directly. (Even then, it might be possible, with a virtual machine that installs a special GPU.)

</comment></comment></comment></comment><comment><USER26> Hulu started to lose when they started limiting the devices that could access it. Ubiquity is the new exclusivity.

<comment><USER27> Or failure is the new success metric, when you are partly owned by a cable company.

</comment></comment><comment><USER28> I think they need Hulu Plus on more devices, and then their current model might work out better. I'm still waiting for it to be available for Xbox 360.

At the same time, I can't remember the last time I watched something on Hulu, so maybe I'm not hurting for it like it would be if I didn't have Netflix.

</comment><comment><USER29> Hulu lost me when they began actively blocking Hulu.com from anything that isn't a desktop/laptop. My Android device has flash, but they disable their site if you aren't on hardware that has their blessing. I'd still see all the ads, so why make your customer's life more difficult?

</comment><comment><USER30> Semi-OT: Has Netflix's selection in Canada improved since they launched? It was kind of pitiful compared to the US.

<comment><USER31> It's still pretty thin compared to the US, particularly for television. There haven't been any dramatic changes since the launch.

</comment></comment><comment><USER32> Hulu lost it's place when it basically stopped working at all in Linux. Today I tried to watch the latest episode of the Office. Even in Incognito mode (no personalizations/extensions) the video never loaded, just the gray background across the whole mid section of the page. In Firefox, it played halfway, then skipped to the end-screen, and upon trying to replay, told me that "This video is unavailable. If this message continues, restart your browser".

So I went back to plan A. TPB: "s07e12 The Office", and I was watching it in VLC 7 minutes later.</comment>


Show HN: Our Django Dash project: Proposalmatic - <AUTHOR> http://proposalmatic.dwaiter.com/

<comment><AUTHOR> For this year's Django Dash three of us made a little web app to help freelancers and small companies manage proposals to clients. Maybe some of you would find it useful.

The code is at <https://bitbucket.org/dwaiter/proposalmatic> if you're interested. Warning: there are definitely a few messy sections since it was built in two days.

<comment><USER2> Thanks! It actually looks pretty great for something put together in the span of 48 hours.

(But I think you guys forgot to filter the proposal queryset by account in the SnippetForm.)

<comment><AUTHOR> Yeah, that queryset could be filtered. It's not really a security risk though -- the worst someone could do is make one of their own custom snippets not appear in their own library.

</comment></comment></comment><comment><USER3> I'm interested in why you opted for a name tied to such a specific use case.

Surely there are lots of other document types where this kind of service could come in handy. Briefly and just off the top of my head: CVs/résumés, marketing mailshots, blog posts...

Was it an intentional choice to try and limit the scope of the application?

<comment><AUTHOR> You're definitely right -- the concept can be used in lots of other places. We talked about this a bunch, and decided that we'd stick with proposals.

If we tried to make the user interface general enough to support any kind of document it would get more complicated. Off the top of my head, we'd need:

        * Arbitrary keywords, not just "client names".
        * More help text to explain how things work, give examples, etc.
        * Probably some more options for the layout of the result, like "show date".

We decided to go with the "do one thing well" approach partly to avoid this extra UI complexity, partly because we only had 48 hours to make it, and partly because "Proposalmatic" is a much cooler/stronger name than "Document- maker".

The site could be easily forked, reskinned and set up for another type of document though. It really fits perfectly with the resume idea -- I hadn't thought of that particular case before. Maybe we should make a "Resume-o- matic" sister site.

</comment></comment><comment><USER4> I was thinking about marriage proposals when I got to the page.

"Use ProposalMatic to save snippets of text that you use often and mix and match to create personalized proposals" This really struck me as odd...

<comment><AUTHOR> Hah, not sure marriage proposals are something I'd want to automate...

And yeah, the copy wasn't number one on the todo list. We'll clean it up and flesh it out once the sites are unfrozen from the judging process.

</comment></comment><comment><USER5> Possibly a naive question but: did you use a css template or something to make that design? I have a hell of a time making sites look that great in 48 hrs...

<comment><USER6> Nope, no CSS template, just raw code. A lot of it is CSS3, and LESS (<http://lesscss.org/>) makes coding it all much quicker.</comment></comment>


The One Step Every Entrepreneur Should Take Before Launching a Business - <AUTHOR> http://www.minisprout.com/web-apps/the-one-step-every-entrepreneur-should-take-before-launching-a-business/

<comment><USER2> FWIW, if I had done this before I launched Quizlet, Quizlet wouldn't exist. In fact, if I had even done a google search for the functionality of Quizlet, it wouldn't exist. Now it's 5x bigger than any of its competitors and a top 400 US website.

Just sayin.. :)

<comment><USER3> Please explain. Why?

Curious :)

<comment><USER2> Quizlet was originally for myself and then for my friends in school. It wasn't even a real business for over a year. I never did any market research or surveys. I just built features I wanted and features my friends wanted, and it turned out to be a thing that a whole lot of other people happened to want. Quizlet has grown 100% through word-of-mouth since it started.

Not saying those things aren't useful, but _nothing_ beats being your own customer. Since I'm not a student anymore and still work on Quizlet full-time, it's super important for me and the whole team to have exposure to our users' experience and mindset. So to hack it, we started a Spanish class at the office so we'd have to use the product. We've also been going on field-trips to various middle- and high-school classrooms around the bay area about once a week.

<comment><USER4> If you don't mind me asking, what's your competitive strategy? It's possible to create something valuable for yourself, and then it turns out other people value it too; but that can attract competitors. Though serendipity can often creates value, it serendipty rarely seems to protect it - it's common that the person who sows doesn't reap. Competitive advantage seems to need a deliberate strategy (though I'm more comfortable creating than defending). Do you find this too?

<comment><USER2> I don't see our competitive position as different than any other typical company. We've got a great product that people love, and we build new things into it that our competitors can't predict or move fast enough to build. We've built a brand that students and teachers know and like.

One deliberate competitive advantage is that we're a free, ad-supported site. Most education products go for a subscription model, and that requires enterprise sales (selling to districts, blech) and fundamentally limits the number of people who will use and enjoy your product.

The ad model only works when you have scale (which we do). If we had been in a position where we needed to make money quickly, we wouldn't have grown into the size and scope we have now.

<comment><USER5> I think this is great, but I'm still unclear about why market researching your idea would have caused you to not pursue it further. If you had asked users when you first started, or even now, "would you use an awesome flashcard/memorization service that is FREE" I would expect the results that came back would encourage the idea of going forward with the business, because I know flashcards are a popular tool for studying and lots of people study.

Are you saying that the number of existing quiz/flashcard sites would create a research result that would discourage attempting another one? It seems like you knew while you were building Quizlet that you had something different in mind, so the only unknown was whether people would use it en masse. As it turns out, you were right, but, and this is a sincere question, was this vision or luck?

Isn't it more accurate to say that the art lies in knowing what questions to ask the oracle, and how to ask those questions, rather than ignoring the value of prophecy?

<comment><USER2> Ya, I'm saying if I had done any googling, I might have found flashcardexchange.com or other competitors that existed when I started it, and settled for one of them. I'd say it was luck that I didn't do any research, and when I decided to build my own thing, I had a clear vision of what I wanted.

All this was when I was 15, and I wasn't thinking about things in terms of startups and competition and so on. It's certainly possible that another way it would have happened was researching the competitive landscape and deciding I could do it better.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I'm wary of online survey results as users just want to get through them as soon as posible. Their motivation is not helping you, it's reaching the carrot at the end of the stick.

I once had a prospective client who wanted to launch a health tourism website, he created a survey and came back to me excited about the results: people wanted to do travel tourism with four companions on average, one user even said he wanted to travel with 8 companions! Of course I was skeptical so I looked into the data.

Turns out it was all bot filled data, the survey company would give a monetary incentive to people who filled the survey, which is an open invitation to game the system.

Bad data is worse than no data at all, because it gives you false confidence in things that might be outright wrong.

I know Google is not naive and they probably filter out questionable data, but I have lost track of all the times I've responded that I live in Afghanistan (first item of the country dropdown) just to get through a sign up form designed by the marketing department.

</comment><comment><USER7> I'm so surprised that this didn't get more coverage when it launched. This is one of the more innovative things to come out of Google in the last few years. I saw an example survey and the reporting interface is pretty rad.

<https://www.google.com/insights/consumersurveys/examples>

</comment><comment><USER8> This doesn't impress me. You get far better and more accurate results from running a Google ad campaign on a mocked up landing page than a survey would deliver.

An ad campaign gives you far more: number of impressions, click through rate, cost per click, key words and phrases potential customers actually use, etc. When it comes to surveys, people lie all the time (Would you hire someone from ethnic minority X? Answer: Of course, some of my best friends are...). People lie all the time, their Google search activity doesn't lie.

<comment><USER9> This is exactly what I do. Knock up a landing page, and stick up an Adwords campaign.

Its a great way to find and engage some initial customers, who will be able to help you shape your product as it develops. Also gives you a great idea on how much it will cost you to acquire customers, and gets you a web presence nice and early.

Oh- and I always talk to my other half about it- she's a complete non-techy so always has a different angle on things, which can be really useful.

I've written out the details steps I use here: [http://blog.crispyfriedsoftware.com/post/19774815792/6-steps...](http://blog.crispyfriedsoftware.com/post/19774815792/6-steps- for-your-startup-before-you-start-coding)

<comment><USER3> Landing pages may capture email addresses and gauge some level of interest. However they don't properly validate your offering.

Ash Maurya (lean cannas) writes about landing pages but also the importance of doing your market research.

Http://www.ashmaurya.com/

<comment><USER9> Yes, I agree-its a good first step, but it isn't sufficient on its own. Also not applicable to some products/services.

</comment></comment></comment></comment><comment><USER10> I think that the title should be:

"The One Step Every Entrepreneur Should Take Before Launching a Business: Survey your customers"

<comment><USER11> YES, thank you! I was just going to rant about tabloid titles like this on HN

FFS people, stop it. Just title your submission _exactly_ what it is about, stop using the language of supermarket checkout line tabloids to try to pique people's interest. If that's the actual article title, don't copy and paste it, but make a better one.

An even more concise example for this one:

"Google Consumer Surveys: survey your target market before launching"

In other news, ironic how the article's header picture is a supermarket.

<comment><USER12> Agree. The question I ask myself is what truth do we get from such survey ? It depends on the people who are responding to the survey. This is just probing. What about product user feedback and product optimization based on the feedback ?

As Ford said, if he asked people what they wanted, the answer would have been faster horses. So the question asked is of course important, and as much as the surveyed people. This may work only for particular ideas. And finaly only the execution will make the difference.

<comment><USER13> People often miss the point of that quote. If he had asked people what they wanted, they'd have said "faster horses."

What they REALLY were saying was "I want to get places faster."

</comment></comment></comment></comment><comment><USER14> This is good - .10 for non-demographic targeted and .50 to target a demographic. But, the fact that the question types are all multiple choice / ratings and don't allow respondents to give short answers like Pickfu is a downer. The insights from people saying why they chose an answer is the most valuable info.

</comment><comment><USER3> Great product. Getting surveys filled out is an impossible task. After three months only 2 people completed our survey. You can offer incentives but you risk creating bias.

<comment><AUTHOR> You're referring to this survey?

[http://sparknlaunch.wordpress.com/2012/04/05/project- mackere...](http://sparknlaunch.wordpress.com/2012/04/05/project-mackerel- please-sir-complete-our-quick-survey/)

<comment><USER3> Yes, that's the one. We have tried various unpaid methods of promoting the survey link. It feels as online users are simply not interested.

This is understandable given the only survey we would be likely to complete is one with an iPad on offer.

We are now planning to call people and ask then a series of questions. The conversion rate may bee slightly higher.

</comment></comment></comment><comment><USER15> If I had any concern, it's that the surveys are used as a means to access premium content. This may or may not effect the quality of answers.

</comment><comment><USER16> This is poor advice. Asking people if they would do something may not give you good data: people are finicky, and may not do what they say they will. Alternate solution: put up a kickstarter. Instead of asking people if they _would_ do something, get them to put the money where there mouth is. Kickstarter is real market validation, not just a throw-away survey.

</comment><comment><USER17> Didn't know this resource existed - Great article!

</comment><comment><USER18> Off-topic: Is it my tired eyes, my broken browser (Chrome on Ubuntu Linux) or a special javastrick: The screenshots appear "suddenly" when scrolling down the page, a bit like a lazy load of images or something similar. NB if you scrolled down to the bottom already, you have to reload the page to see it, and it seems less noticeable than at first load.

<comment><USER19> The page loads [0], which, given its name, probably means they do some lazy loading. I've seen it too.

[0] [http://www.minisprout.com/wp-content/plugins/jquery-image- la...](http://www.minisprout.com/wp-content/plugins/jquery-image-lazy- loading/javascripts/jquery.lazyload.mini.js?ver=1.5.0)

</comment></comment><comment><USER20> Every survey that asks "Would you pay for..." is flawed. I would pay for many things but I am not paying for them. The best way to really get some data is to set up a sales page, put your price there and count the clicks on the Buy Now button. Use Adwords or whatever to drive the traffic. This works much better than surveys.

</comment><comment><USER21> Actually, not to be cynical, but the first step is to realize that your first ten ideas are probably going to be crap, and save yourself the time of even trying market research on them.

<comment><USER22> If you have ten ideas and do nothing, why would the next ten ideas be any better?

Unfortunately you don't get better at having ideas by simply having more ideas. You get better ideas because you have experience in trying to use them.

</comment></comment><comment><USER23> "Every Entrepreneur". Yeah right. What about when your making something people don't even know they want yet.

<comment><USER24> Well, they may not know what they want, but what you'll be selling solves a problem. You can still validate based on that.

</comment></comment><comment><USER25> how do they keep people from filling in bogus answers just to get through the survey?

<comment><USER26> (I work on the project)

Some algorithms to detect users consistently giving bad answers, but in general it is easy enough for users to give correct answers. Check out the response time histograms on the example surveys.

We also have a whitepaper here comparing our results to other survey providers and known results: [http://www.google.com/insights/consumersurveys/static/consum...](http://www.google.com/insights/consumersurveys/static/consumer_surveys_whitepaper.pdf)

</comment></comment><comment><USER4> > It's really hard to design products by focus groups. A lot of times, people > don't know what they want until you show it to them. - Steve Jobs

But it depends on how new your product is; e.g. Macdonald's can calculate demand for new store locations.

</comment><comment><USER27> Has anyone had great success with Amazon's mTurk?

</comment><comment><USER28> I didn't know this, thanks for the link. But why google is doing this ? Is survey business that big ?

</comment><comment><USER29> oh this one is funny! did i get that right? i will have to pay google this moneystuff to create even more market research data for them? (because as the survey is done on their site the data will end up on their servers)

well, call me a greedy bastard, but in my opinion they would have to pay me, would't they?</comment>


Teaching your children a second language - <AUTHOR> http://www.kumon.co.uk/blog/is-learning-a-foreign-language-good-for-kids-at-a-young-age/

<comment><USER2> I've always though that was a good idea - that's why I'm teaching mine Factor.</comment>


Veloren: An open-world, open-source multiplayer voxel RPG written in Rust - <AUTHOR> https://gitlab.com/veloren <comment><USER2> This looks pretty cool. It's nice to have an open source Rust game. Getting started developing a game in Rust is a bit rough, so having a reference like this is very helpful.</comment>


Why Microsoft's Surface RT Failed - <AUTHOR> http://mashable.com/2013/07/19/surface-rt-failure/

<comment><USER2> A: It's too early to tell if it failed. B: If it were to fail it would be exactly why every other Microsoft failure has ever failed. It is simply ahead- of-its time. We all know that Microsoft had smartphones and tablets years (not decades, but close) before anyone else. The only reason that they failed is that they offered too much - consumers were simply not ready for those capabilities and those capabilities scared them. The iPhone 1 was stupid enough (sorry, it's true, my HP IPAQ or HTC TyTN II could do more than the iPhone 1 could ever do) to not scare the market.

A confusing name: Is "RT" all that hard, or if it really does confuse someone "that Microsoft tablet" would work just as well. Where are the apps: true. A better alternative exists: no. A simpler alternative exists. The market isn't ready, let's not confuse consumer perception with complexity.

Mark my words, in 6 years time Apple will come up with exactly the same thing and everyone will lose their minds over how innovative and truely revolutionary it is: simply because the market is ready for a product such as that.

Let the Surface RT (and WinMO) be a lesson - you might have a game-changer of an idea, but it is worthless until the majority of the market able to comprehend what you have to offer.

<comment><USER3> A: No, it's not too early. [https://news.ycombinator.com/item?id=6067152](https://news.ycombinator.com/item?id=6067152) Microsoft have taken a $900 million write down for it. That's not something you do for a success or success-in-the-making.

B: All of Microsoft's failed products (of which there are many) are ahead of their time? Or maybe most were just not properly executed? Occam's razor and my own experience with Microsoft's products both vote for the latter explanation.

> Let the Surface RT (and WinMO) be a lesson - you might have a game-changer > of an idea

I think the lesson would be: "Listen to the market; it won't blindly eat everything you serve the way it does on the desktop, just because you are microsoft". WinMO had a good market position for a long time, indicating that the market did comprehend. It just didn't keep up with the times.

</comment></comment><comment><USER4> They launched Windows RT and regular Windows 8 the wrong way around. In 2-3 years time, when the Windows app store is more mature, Windows RT will make more sense so that people don't need desktop mode as a crutch.

At that point they should try again, but with a fully Metro UI, i.e. ditch desktop mode (including a Metro version of Office). Also needs a different name, maybe SurfaceOS, it's too confusing for users with a name that includes "Windows", and has a desktop that kinda-sorta works like regular Windows.

Saying that, I think the Surface Pro and other Windows 8 tabs are going to get a lot better as x86 chips get better with power consumption, continuing from Haswell. Seems Windows 8.1 is solid step forward.

</comment><comment><USER5> I actually own one - I was curious. It is shelfware next to my chumby.

</comment><comment><USER6> They should just remove the artificial restriction that desktop apps aren't allowed, and I'd buy one immediately. (Windows RT is actually a complete port of Windows to ARM, it just refuses to run non-signed desktop apps.)</comment>