If we are to include less ambitious stuff, Google Video, Orkut, Chromebooks (never went far), Reader, Google Code, Dart, nothing much came out of Morotola, etc.
And let's see were those "self driving cars" will go, market-wise...
> Dart pivoted into a compile-to-JS language, but is still alive
Dart started as a compile-to-JS language for web use with a VM for server use, with an browser-hosted VM for development with a long-term plan that compile-to-JS might not be necessary on the web.
And its still a compile-to-JS language for web use with a VM for server use, with an browser-hosted VM for development use.
Google Video, and Orkut, were complete failures and no longer exist. Successful products don't disappear without a trace. If they are closed by management when they otherwise might have succeeded, that is failure.
Reader was a failure according to Google itself, which closed it due to supposed lack of interest. Once again, if the decision to close it was an error by your criteria, then they failed.
Of course if we go back to the original question, Orkut and Reader were hardly "moonshots" in the first place (and Google Video was arguably just a standard project launch).
> Google's own canonical example of a moonshot is Android
Is it?
> By that definition, Orkut and Reader qualify just fine
If everything is a moonshot, nothing is, etc.
AFAIK both projects were just 20% time projects scaled up to three or four people[1]. A "moonshot" is obviously a wishy-washy term, but opportunity for success doesn't seem to be sufficient to call something that.
If you watch a video on youtube today it's actually hosted on googlevideo.com or something (i know because uBlock). I assume they threw the youtube backend away when they bought it :) So in that sense google video is still alive, just a different name.
If you are Google that reads as "Orkut only got traction in Brazil and India, hence failure". Maybe they could have sold it to some smaller company, but they tried to move the customers to their other services instead.
Chromebooks are pretty popular. The first generation wasn't very good but the more recent ones are selling well.
Reader was very popular relative to the size of the RSS reader market.
Google bought Motorola for the patent portfolio and sold off the rest, so I'm not sure how that was a failure. Motorola also turned around their mobile division with the Moto X under Google (over 100% increase in mobile sales due to the Moto X and company line of products)
I remember Orkut being very popular in Asia for a while.
All of that I wont argue with, except the characterization that reader was a success because Google owned the market.
I dont see how G closing down reader could have that count in the success column, especially considering how much bad blood it bred for G (and how little effort it would have likely meant to maintain it.)
Yes, they sell decently, but do no represent any profit for Google (which gives the OS for free).
It's around 5-6 million units sold anually, but, as Google themselves said, Google don't make any money of off them.
Samsung, Acer, etc, who produce the units do, but again, in total it represents a tiny slither of laptop profits due to the small margins. Most Chromebooks (70%) go to the education market as cheapo laptops.
I would imagine that Google indirectly profits by having more users using Google as their default search engine and by encouraging the world to rely more on the web.
Edit: Also, in the past Google would pay Firefox to have its users use Google as the default search engine and Google gets the equivalent of this for free with each Chromebook sold.
They suffer from the gulf state problem where they make so much money from one thing that nothing else will ever be important enough to really be successful.
Since Dart never went anywhere adoption-wise, and even abandoned plans for its own VM in browsers (not to mention its purpose obsoleted by the announcement of WebAssembly -- since devs will be able to use ports of much more established languages for web programming).
And since Google-made Chromebooks never sold well, and those by third parties (Acer, Samsung, etc) don't make much money for their manufacturers and no money at all for Google, and all constrained to the niche educational market (schools buying them for their students).
> since devs will be able to use ports of much more established languages for web programming
Sure, they'll be able to use any language they like, as long as it's C or C++. :)
There is currently no story for using any high level language (read: language that uses GC) like Ruby or Python as a web language by way of WebAssembly.
>There is currently no story for using any high level language (read: language that uses GC) like Ruby or Python as a web language by way of WebAssembly.
Actually that's part of the whole point of WebAssembly -- as Eich put it. It's not just to speedup emscripten style ports of C/C++ programs.
Eich's words: "Bottom line: with co-evolution of JS and wasm, in a few years I believe all the top browsers will sport JS engines that have become truly polyglot virtual machines".
I understand that's his goal, but I believe actually getting there is quite a ways off and may ultimately never happen. Of course, you can never say never on the web, but going from supporting C/C++ to supporting, say, Ruby or Python is a pretty fundamental change in how the system works.
A modern GC is a large, complex beast. Python, Ruby, Lua, etc. all have their own implementations of them, and those implementations are specific to the semantics of those languages. (For example, Python's early finalizers. Ruby's FFI, etc.) That's a big blob of code for you to push down the wire with your application every time the user hits your site.
Also, that GC doesn't know how to play nice with the browser's own GC. If you have an event handler that has a reference to some Ruby object that in turn has a reference to some DOM node, neither GC can trace through that path and tell when those objects can be collected. That means you get memory leaks.
On top of that, the language implementation itself is large. The Python executable on my machine is 2 MB. Do you want to add another 2 MB to your app? Is Python enough better than JS to justify forcing all of your users on their crappy mobile networks to download that before any interactivity begins on your page? What about when you start using the additional 45 MB of standard library that comes with Python?
Also, how do you make those standard libraries work in a browser? Who is going to rewrite them all to stop using the native OS libraries they currently use and instead rely on APIs that are available in JS?
That's not to say this is an insurmountable problem. But my belief is that it's a big enough headache to outweigh the benefits you would get from writing your app in another higher level language.
Now, if your language can compile to JavaScript and has a decently small runtime library, that's a different story. At that point, you're back to only one GC and relatively little overhead for your language's semantics and core libraries. It means you don't have to worry about a large existing standard library that #includes everything under the sun.
This is why I think CoffeeScript, ClojureScript, Dart, etc. are feasible. But I don't think anyone will be writing web apps in Ruby or Python anytime soon. Languages that look syntactically similar to them (Opal, Red, Pyjamas, Brython, etc.), sure. But the real deal where you can have some app that does, I don't know, "import requests" and have it actually work in a shippably-sized web app? I think that's going to be a much harder path.
It's a great goal for the WebAssembly folks to work towards, but it's an aspirational goal.
They were absolutely pitched as huge ideas that would change everything we know about email and social networks. Bearing the scars of their public failures, Google started calling new projects moonshots to shape perception of the programs as chasing ideas, while preemptively deflecting any criticism of their readiness or desirability to large markets. They are not materially different from moonshots except in presentation.
Circles for different messages to different groups, as well as the universal profile for logging into all your favorite Google services. It's not my fault these were harebrained ideas, but they were presented as revolutionary. The ideas are still arguably revolutionary (Slack delivers where Wave failed) but Google's execution was lacking. Same fundamental issue facing so many of their other programs.
And the Russians dreamed of going to the moon but that's the rub with consumer products - the market has to accept them for it to be an accomplishment. Google thought they'd found the magic recipe and pitched it as something for everyone that was a huge breakthrough. Being first with features or flows doesn't matter at all. The only thing that matters is making it relevant to users' lives, which all parties failed at. Circles is a bad model for a mass market.
They were absolutely moonshots. Reforming the entire way we do realtime communications? Reforming the entire way we do social interaction? Total moonshots, they just failed, but if they succeeded they would be billion dollar businesses.
I think the implication about a moonshot is that nobody has been to the moon before the moonshot. The thing about Facebook's lunch is that lunch happens ever day at noon.
