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...
Orkut was wildly successful in Brazil and India, until they stopped building it for Buzz and Plus
Reader was hugely successful, which is why the outcry on its closing
Chromebooks are doing great, atleast on Amazon, the world's biggest retailer.
Dart pivoted into a compile-to-JS language, but is still alive
Motorola streamlined it's product lineup under Google and is doing fairly okay for Lenovo
Calling above items as failure is inaccurate. None of them were moonshots btw.
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.
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.
The rest I would agree with.
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.
[1] http://massless.org/?archive=2007/05/about-google-readers-bi...
Yes. They first used the word when referring to Andy Rubin's departure from Android.
Umm, no. Reader was not hugely successful. Users loved the idea of using Reader but they did not actually use it.
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.
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.
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.)
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.
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.
E.g. with all the billions developing Android, buying Motorola etc, they still make the large majority of mobile ad money on iOS devices!
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.
It's 2015 and companies compete for user timeshare, not dollars.
E.g. you can open a web application selling $10 for $5 today and I guarantee you it's gonna be a huge success.
Dart and Chromebooks failures? Since when
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).
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.
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.
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".