Google's iron grip on Android: Controlling open source by any means necessary - <AUTHOR> http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ <comment><USER2> Most of the examples of Google closed apps that are not part of the AOSP release are in fact apps that are based off of Google data-center services. Would it really help Samsung if the source to the Gmail app was open? Since Google controls the server side, and the client-server protocol, it limits the amount of innovation they can do.

The web equivalent would be like claiming that Chrome OS isn't open because the source to Gmail isn't available.

Google is stuck behind a rock and a hard place. If they don't try to create incentives for a unified experience, they get bashed for encouraging fragmentation, if they do assert a level of control, they get bashed for not being completely open.

<comment><USER3> > Google is stuck behind a rock and a hard place. If they don't try to create > incentives for a unified experience, they get bashed for encouraging > fragmentation, if they do assert a level of control, they get bashed for not > being completely open.

This is exactly the position Microsoft was in during the mid-1990s, even before they went after Netscape. The article is saying that Google is even applying some of the same strong-arm tactics to keep OEMs in line. Fortunately, Google can point to Apple and say they're not a monopoly the way Microsoft was in its market. Plus, Android still looks really open compared to iOS.

<comment><USER4> Android is open enough to replace all Google apps with your own (Samsung) and open your own appstore (Amazon). Also companies are completely free to not pick Android (Tizen / Firefox OS / ?) and they are free not to license the Google apps and put their own or (other) open source ones. It would be hard to make Google out to be a monopolist via that route.

MS was different; there weren't much alternatives and the alternatives which were there were squashed by MS. People currently want the apps in the appstore; they want to play clash of clans; they don't care about the Google gmail app. This being the same bubble world as the chromebook thread on HN yesterday; tech people think non tech people actually notice what they are running; they generally don't. If they can play the games their friends are playing and if they can use 'the software' they are used to they are happy. What brand it is is not important.

As an example; when I sit with any of my family members (they are all non tech), they will say 'I will open up Word now' or ' I will open up Excel now' to me when we need to organize something or go over numbers of one of the companies. What pops up definitely never is Word or Excel but rather Libre Office or Google Docs or some free Android/iPad variety. No-one I know actually has or uses MS Office; they use the terms because they don't know 'spreadsheet' and 'word processor' is a mouthful. They don't miss Windows and would even mostly hate it if they had to work with it now (after tablets or chromebooks and even Macs, Windows for non-tech people Windows seems incredibly hard and tech to use).

All these alternatives and Android being deployed by many different companies in different forms would make it hard to call Google a monopolist on that grounds. Samsung could turn into one though.

<comment><USER5> Did you even read the article?

And if you want to stay on the technical side.. then what about contributors? I've helped port android to a couple devices. I had no idea google had a contract obligation with hardware makers that my work should have to be used in one way or another. I feel dirty.

edit: the Acer example goes exactly against what you mention. They tried to ship a fork, with some of the substitutions you mention. google released the layers.

<comment><USER4> I read the article; if you want out of their grip you can. You just need to provide alternatives for the Google apps and appstore. That is not trivial, but for a company like Samsung that wouldn't be that big of an issue either.

Acer tried to release it while still wanting to be in the 'Android family' (Open Handset Alliance); they didn't have their own substitutes and didn't want to make a clean break with Google (OHA). If they wanted that and would have provided an appstore, they could've.

</comment></comment></comment></comment></comment><comment><USER6> When someone like Github does this (make some parts of their code open-source, but others closed-source), journalists don't write critical pieces about them, do they? I mean, Google leaves a bad taste in my mouth since they started shuttering services like it was Christmas at the Google Service Chopping Block, but I don't see them being actively evil here.

It's all according to the previously openly aired plan. Google keeps _all_ of the existing code open source. Anyone who wants to build a fork can do so. Now if they want a hardware platform to run on, go find one outside the Open Handset Alliance ecosystem. It's fair game -- if a hardware partner thinks that one of Google's competitors can provide a better Android fork, they are free to leave the Alliance and go partner with that competitor. _They will still get an enormous amount of code for free in AOSP._ They just won't get all of the services that Google is building specifically for its own version of Android. How is any of this maintaining an "iron grip" in any way? Just contrast this with Apple where it is the sole owner of everything to do with the OS and app marketplace.

<comment><USER7> AOSP is so open that the previous AOSP leader at Google quitted over the lack of openeness.

<comment><USER8> That's a mischaracterization of his own comments on why he left. It had to do with open sourcing GPU drivers, which is probably an issue with other vendors, not Google.

See: [https://plus.google.com/112218872649456413744/posts/9HHRURor...](https://plus.google.com/112218872649456413744/posts/9HHRURorE7g)

<comment><USER9> It was Google's choice to put that hardware into the phone, and it was their choice not to pressure qualcomm into being more open.

Your argument itself is also somewhat of a mischaracterization, because at least Google could have wrestled redistribution rights for the binary drivers, thus making AOSP actually usable on the nexus, and they didn't even bother with that.

Vendors are a convenient whipping boy when don't care about openness but wanna look like you do.

<comment><USER10> There's a very, very simple problem with your argument:

[https://developers.google.com/android/nexus/drivers#razor](https://developers.google.com/android/nexus/drivers#razor)

<comment><USER9> and here is the problem with yours, from the EULA:

         Subject to the terms of this Agreement, Licensor hereby grants to
         You, free of charge, a non-exclusive, non-sublicensable,
         non-transferable, limited copyright license, during the term of
         this Agreement, to download, install and use the Software
         internally in machine-readable (i.e., object code) form and the
         Documentation for non-commercial use on an Authorized Android
         Enabled Device and non-commercial redistribution for academic
         purposes only of a reasonable number of copies of the Authorized
         Android Enabled Device Software (the "Limited Purpose"). You may
         grant your end users the right to use the Software for
         non-commercial purposes on an Authorized Android Enabled Device.
         The license to the Software granted to You hereunder is solely for
         the Limited Purpose set forth in this section, and the Software

This makes it entirely impossible for AOSP to distribute the drivers

</comment></comment></comment></comment></comment></comment><comment><USER11> > Google was terrified that Apple would end up ruling the mobile space. So, to > help in the fight against the iPhone at a time when Google had no mobile > foothold whatsoever, it was decided that Google would buy Android. And > Android would be open source.

This is blatantly false. Google bought Android in 2005, two years before the iPhone was announced.

<comment><USER12> Android clearly went in a different direction post-iPhone.

<comment><USER13> Agreed.

All those videos of Android demo or prototype units clearly showed Android was a Blackberry clone (just look at that tiny touchpad for navigating around Android OS) and changed its design direction after iPhone made its appearance.

<comment><USER14> nonesense. Android is a software platform that companies can build sofware and devices on. Android is not a device, and it's not an "operating system" in the sense that people use this word today. It is a fundament that you can build an operating system with, and a cross platform that allows applications run on different software, as long as this software is based on Android.

If you want to show off what Android can do, you put it on all kinds of devices that people are using at the moment. If everyone has a Blackberry, you want to show that you can make a software for Blackberrys based on Android. If everyone is hyped on digital cameras, you show a software and ui for such a camera.

Android used to have 3 prototypes in its early stages: a blackberry type, a tablet-type device, and the device that later became the Tmobile G1, the first android phone. The platform never changed course, and it clearly never was a Blackberry clone.

<comment><USER15> "If you want to show off what Android can do, you put it on all kinds of devices that people are using at the moment."

I'm not so sure about that. Blackberry didn't do that, and neither did Apple...

<comment><USER14> Not sure I understand your comment. Neither Blackberry nor Apple developed a cross platform technology meant to run different hardware/software configurations. So of course they did not demonstrate how a platform runs on such configurations.

</comment></comment></comment></comment></comment></comment><comment><USER16> The only real thing that seems "evil" is the requirement for OEMs to not manufacture _any_ devices compatible with non-Google forks. The rest of it seems pretty necessary in order to keep carriers and OEMs in line. A lesson Microsoft learned, and why Windows Phone started off by allowing the user to remove any pre-installed crap.

If Google didn't do any of this, and was totally altruistic, Samsung and others would already have completely screwed things up.

While it's certainly very much to Google's benefit, it also benefits most users because overall, Google has done a far better job than any OEM regarding user experience.

<comment><USER10> In fact, the boundaries of the compatibility requirement are pretty fuzzy.

For instance, the Acer/Aliyun situation is more complicated than presented. The Aliyun app store was distributing pirated apps (including pirated Google apps): [http://www.androidpolice.com/2012/09/15/aliyun-app-store- con...](http://www.androidpolice.com/2012/09/15/aliyun-app-store-confirmed-to- be-distributing-pirated-android-apps-many-from-another-pirate-site/)

It seems obvious that Acer would have wound up in hot water with Google over this somehow, though it is odd that Google decided to focus their complaint on compatibility (rather than on Aliyun's piracy).

On the other side of the coin, many Android OEMs have distributed (and still distribute, so far as I know) devices without Google apps for the Chinese market (including Samsung, ASUS, Huawei, and even Motorola [1]). So far as I can remember, these were always essentially the same as non-Chinese devices except that they came with a different ROM that didn't include Google Apps. Nevertheless, that means that there's some scope for making non-Google Android devices, we just don't know how far it goes. Maybe if the HTC/Amazon rumors turn out to be true, we'll find out more.

[1] Though I think Motorola's efforts were shut-down post-merger because of Google's China policies.

</comment></comment><comment><USER17> I think alot of people misunderstand what open source means. It's nothing more than allowing people to see the source code, and use it (including forking).

Open source doesn't require you to cooperate with anyone, it doesn't require you to give away access to APIs, it doesn't require you to do anything beyond whatever is explicitly stated in the license.

Google, Canonical, Oracle, IBM, Red Hat, SUSE, etc... aren't required to be good team players or corporate citizens. They're just required to abide by the terms of the licenses on code they use...

<comment><USER18> Well, there is a philosophy (or rather, various different philosophies) that go along with the legal structures, and different projects have different levels of adherence to those ideas.

It eventually comes down to perception of value. Part of the original attraction of Android was its openness, if Google is now closing off substantial functionality, to head off competition, then it's not unfair for people to re-evaluate their enthusiasm for the product.

<comment><USER19> > Part of the original attraction of Android was its openness, if Google is > now closing off substantial functionality, to head off competition, then > it's not unfair for people to re-evaluate their enthusiasm for the product.

Very well put! Its not a legal perception that theres something wrong about what they are doing(and nobody are saying that they cannot do it in the legal aspect).. its a betrayal of some part that make people defend android for what it is, a open source project.. its the ideal behind the project that is being broken

If its not like that anymore, the same people that support it for its openess should be aware of it.. and see that things are actually, gradually and silently changing..

<comment><USER20> Perhaps there should be a phrase to mean "open source in name only." I wonder if all of this is related to Richard Stallman's dismissal of projects that claim to be open source, saying that it isn't enough unless it's "free software."

<comment><USER17> RMS is satisfied with anything that has a GPL licence. He's always supported creators rights to manage projects however they choose, and sell software as they choose. Google would fall short simply because the BSD licence isn't copyleft, but not for much of what they're being accused of here...

<comment><USER21> You are perfectly right regarding stallmas posted opinion regarding the GPL license.

I doubt however that RMS would be happy with open/free code being replaced by closed one as exemplified in the article. That has of course nothing to do with permissive and copyleft, and all to do with lock-in, proprietary practices, and project management.

<comment><USER17> He'd likely just say it was never fully free to begin with, because of the license. Not to mention, all the Google apps in question connect to SaaS backends which are closed anyway.

Personally, I don't see the problem with what Google is doing, I would prefer 100% open software myself, but Google would never open-source their services' code, so the fact the apps are closed-source doesn't really make a difference.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> As an Android developer, I love that Google is doing this!

Android has come a _very_ long way in the last few years in terms of usability and design. A large part of this has been due to an increasingly uniform design language and feel. That, and the new distribution model for what are basically Android updates (Google Play Services) has made Android feel more polished and actually allowed it to stand on its own against iOS. It also means that developers like me don't have to spend nearly as much time worrying about fragmentation in the traditional sense. Each day the percentage of people using sub-ICS phones falls, and we all get one step closer to the day we can support ICS+ only.

However, companies like Amazon would force me to rewrite the maps integration, the sign-in portion, the wallet, etc... Amazon did a great job of replicating Google Maps API V1 but they have yet to mirror V2 and don't mirror the other components I mentioned.

Aside from fragmentation and developer sanity, the article mentions another key point here:

"[M]any of Google's solutions offer best-in-class usability, functionality, and ease-of-implementation."

Exactly! Google APIs are not perfect, and there's bugs (like when Google Maps broke map markers on high resolution phones like the HTC One). But generally speaking, I'm really happy with the quality of the APIs and services. In an ideal world, Amazon and Google would work together to provide great and uniform single-sign-in APIs, great maps, etc... As it currently stands though, I don't believe either party is interested in doing so. Prisoner's dilemma?

</comment><comment><USER18> > While it might not be an official requirement, being granted a Google apps > license will go a whole lot easier if you join the Open Handset Alliance. > The OHA is a group of companies committed to Android—Google's Android—and > members are contractually prohibited from building non-Google approved > devices. That's right, joining the OHA requires a company to sign its life > away and promise to not build a device that runs a competing Android fork.

...

> This makes life extremely difficult for the only company brazen enough to > sell an Android fork in the west: Amazon. Since the Kindle OS counts as an > incompatible version of Android, no major OEM is allowed to produce the > Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for > its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, > Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, > Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle > manufacturing out to Quanta Computer, a company primarily known for making > laptops. Amazon probably doesn't have many other choices.

That is fairly incredible, I'm surprised it is not an anti-trust/competition issue.

<comment><USER23> Are you serious? What other commercial OS can I do a competing fork of? Don't you see that the same restrictions apply to all other consumer OSs (iOS, WP, etc) by simply being closed-source?

<comment><USER18> That's a fair point, but Android is open source (and indeed was heavily marketed on that basis). They don't get to use any mechanism they like to make the situation comparable to their closed competitors. Their situation is also not comparable to iOS, WP, etc, because of their position of market dominance, just the same as the situation with Windows and Mac OS back in the day.

<comment><USER23> _That 's a fair point, but Android is open source (and indeed was heavily marketed on that basis). They don't get to use any mechanism they like to make the situation comparable to their closed competitors._

Android is open source; their services and corresponding apps aren't, and that's what they use as leverage. Not allowing them the same rights over those as other companies have over their proprietary software is essentially punishing them for having released something as open source.

And yes, Android _is_ open source, and the Kindle Fire proves it. The fact that some people expect Google Play et all to be bundled is not Google's fault.

 _Their situation is also not comparable to iOS, WP, etc, because of their position of market dominance, just the same as the situation with Windows and Mac OS back in the day._

But Windows was, and while Microsoft was criticized for a lot of anticompetitive plays, not allowing people to create _forks of Windows_ was never one of them. Not to mention that Google does allow you to create forks of Android, they just don't give you access to their services on top of that.

</comment></comment></comment></comment><comment><USER24> > Google does everything in-house. The company gets Maps and all of its cloud > services basically for free.

This statement is utterly false. In-house does not mean free.

<comment><USER18> All of its Maps data and many of its APIs already existed for Google Maps on the desktop. Within the mobile space, and relative to a mobile-only competitor, Google's access to that data is effectively free.

<comment><USER25> Map data for mobile isn't free even for Google. Google buys licenses to the data from a few map data providers, and as there was effectively a duopoly in global map data, those licenses have very strict terms of use. To use that data for e.g. real-time navigation assistance in mobile requires a different, much more expensive licenses.

<comment><USER18> Good point, thanks for the correction.

</comment></comment></comment></comment><comment><USER26> While I can see the point of this article, it's being cast in a much more dramatic light than necessary. Phrases like "While Google is out to devalue the open source codebase as much as possible" seem hyperbolic to me.

<comment><USER27> I agree. While it does make some good, disturbing points, you can tell they had to stretch to make some of the other points.

</comment></comment><comment><USER28> What's really annoying is when the Google apps start becoming worse to make Google more money. I never open the app store without wanting an app, but it constantly tries to sell me books and movies and stuff like that. They even have separate Google apps for reading and movies, so shoving it in the app store is just a money grab making my usage more difficult to shove some ads in my face. Were these apps open source people could just fork, but we're stuck going along with Google until they mess up so bad it makes sense to switch over entirely to Amazon App store, Samsung Apps Seller, etc. and the equivalent for everything else.

<comment><USER29> This is an opportunity for Yahoo. The article mentions that OEMs can't leave because they're afraid of losing Google services, Yahoo can be that replacement. They've been making beautiful mobile apps lately and they have some very polished services. They are a pure play service provider who isn't trying to compete with the OEMs; they have no conflict of interest.

If you work at Yahoo, this is something you should run up the chain. A relationship with OEMs would solve their problems, and allow you to get a foothold in mobile that you haven't been able to before.

<comment><USER30> Yahoo internals were even discussing ideas of creating their own fork of Android, way back in 2010. Nothing happened.

</comment></comment></comment><comment><USER31> Correct me if I'm wrong, but isn't Linus Torvalds famous for his iron grip of Linux? In a very different way, to be sure, but it's my understanding that just because you make something open source doesn't mean you have to (or even should) relinquish control.

I think it's also pretty standard to open-source the core and keep the baubles proprietary. GitHub, for example, made their git interaction library open- source but their git hosting service itself is closed, as far as I know.

<comment><USER32> Every open source project has someone (or some group) in control, and contributions can't land without their say so. But anyone who feels that the current leadership is doing it wrong can fork the code and try to persuade people to use their version. This is very important to the way open source software works.

Google have a level of control beyond that: they undermine anyone trying to fork Android by not letting them use Google's apps and services (even as they allow such use on competing systems like iOS).

<comment><USER33> I have a feeling that if an Android fork actually started to gain serious market share, Google would very quickly allow them to use GMail, Youtube and the other apps.

<comment><USER34> Amazon have a Kindle product that is an Android fork with serious market share. I don't know if Google has anything in the Kindle market place with GMail etc.

<comment><USER33> The Kindle Fire doesn't have the Google Apps, and might never have them, but the Barnes&Noble Nook HD does (I have one), starting a few months ago. It originally didn't (I suspect for the same reason as the Kindle Fire), but Google later allowed B&N to run the apps (B&N even replaced their custom web browser with Chrome, a move which not everyone liked).

</comment></comment></comment></comment></comment><comment><USER35> Part of my business is about creating Android-based embedded systems. So far, none of what Google has done impinges on using Android as a basis for an operating system for appliance-like devices. The main problem is that current development of Android is not done in the open. But, so far, the advantages of using Android's UI stack and other APIs in "appliance OS" applications outweigh the annoyance of sporadic updates to the AOSP code-base.

If you want to compete with Google, using Android poses a choice: If you make Google-branded Android devices that use Google's proprietary apps, you will have to give that up in order to use Android with other ecosystems.

Thirdly, if you want to use the Google ecosystem in a product, you have to use all of it. You can't substitute someone else's location services, for an example that was litigated.

Google could develop Android in the open and retain the same level of control over OEMs, and I think they should.

Google appears to be inconsistent in enforcing restrictions on OEMs. OPhone OEMs also make Android handsets, despite the fact that OPhone is an Android derived product. Maybe that arrangement pre-dates Google's current policies.

</comment><comment><USER36> > Android has arguably won the smartphone wars, but "Android winning" and > "Google winning" are not necessarily the same thing.

This is false. Google wins when more people use the Internet. Android is fulfilling its initial goal incredibly well: offer a free and open-source mobile OS to encourage mobile device proliferation.

Android is doing exactly what it was designed to do.

<comment><USER37> The article's description of what we're to happen if Apple did not have competition is quite accurate and write frightening. Even with the north American market share that Apple has they abuse it where possible.

<comment><USER36> Yes I agree.

Android is not about North America. Android is about India, Africa, and China.

<comment><USER38> It is banned from China (AFAIK, they use Alibaba fork). India and Africa are mostly untapped markets. The 80% market share come from America and Europe

<comment><USER39> Android is not banned from (or, in) China. It is hugely popular. See, for example, a popular website's offerings for Android telephones: [http://mobile.139shop.com/commend/170__001_1.htm](http://mobile.139shop.com/commend/170__001_1.htm)

Interestingly, in China, and this is personal experience not a market survey, the more one moves away from big brand manufacturers of Android telephones, the more pure / bare-bones / no manufacturer or telecom added applications the Android install is (again, China experience only).

I am sitting in mainland China with an Android phone in my pocket. 518 Yuan can easily buy a bright 5 inch screen, 4 days battery life (my average usage) with WiFi on most of the time, only one manufacturer installed app (Baidu input; being in China, this useful), 1.2GHz processor, 1GB RAM, 2 SIM card slots, SD Card slot (free card included, only 2GB, but free is free), 5MP camera (2MP reverse), user serviceable battery.

</comment></comment></comment></comment></comment><comment><USER40> "In an ocean with great waves, whales fly into the air unnoticed, but in a calm pond, even the tiniest minnow makes a ripple." -confucius

When the iPhone debuted, no doubt Google sensed the impact, and Apple's ability to create an effective closed ecosystem had already been proven with iTunes. I believe that Google wanted to undermine the market long enough to understand it. True enough, "android winning" was not the same as "Google winning," but it did mean everyone else "losing." I believe that for Google, Android started as a strategy in search of a goal. It was a smokescreen to prevent Apple from taking a dominant position by default. As the data poured in, they began to understand how to leverage it, and the Nexus line became an expression of such understanding, working to establish more control, and hopefully emerge from the smokescreen they had created.

<comment><USER41> I will only buy / recommend nexus phones. Knowing that the phone will be updated quickly and for a long time is worth a premium, rather than being a cash in strat for Google.

<comment><USER42> my impression of nexus devices is that you are tied to the package of google services. is this so, or can a nexus-user break free from google's domain and enjoy the benefits of a quality low-cost device without being beholden to the google ecosystem?

<comment><USER43> From what I know, for the 2012 Nexus 7 at least, there are lots of custom ROMs, some of them without Google Apps. There are even alternative operating systems like Ubuntu Touch. I don't know if other emerging mobile OS such as Firefox OS and Sailfish have been ported already or not, but if not, I'm sure they will, given the market share of the device and the amount of people interested. Ultimately, you can also run GNU/Linux with the usual light desktop environments.

</comment></comment></comment></comment><comment><USER44> Well, this is really arguable. The "Iron Grip" is the modules that happen to be dependent on authenticated API calls to the servers that Google owns and maintains.

I'd fully support their modules that connect to the cloud servers being open source / GPL / etc, but to expect them to open them up to unauthenticated requests is untenable and leaves them way open to abuse / lack of rate limiting / making the service a bad time for all involved.

<comment><USER18> > Well, this is really arguable. The "Iron Grip" is the modules that happen to > be dependent on authenticated API calls to the servers that Google owns and > maintains.

It also consists of witholding access to those APIs if a company uses a competitor service:

> Another point of control is that the Google apps are all licensed as a > single bundle. So if you want Gmail and Maps, you also need to take Google > Play Services, Google+, and whatever else Google feels like adding to the > package. A company called Skyhook found this out the hard way when it tried > to develop a competing location service for Android. Switching to Skyhook's > service meant Google would not be able to collect location data from users. > This was bad for Google, so Skyhook was declared "incompatible." OEMs that > wanted the Google Apps were not allowed to use them. Skyhook sued, and the > lawsuit is still pending.

</comment></comment><comment><USER45> What's interesting is how having a mobile OS is now only one part of the offering needed to be successful, and is arguably the easiest part.

To be successful on mobile you also need a fairly extensive layer of services. Some of those (web, mail and so on) are easy to bolt together but others such as maps and app stores are far harder and are about data and commercial deals as much as they are about software. While it would be wrong to say that these services can't be opened up, in many cases doing so isn't as straight forward as sharing source code.

It doesn't feel as if Google has changed so much as what it means be a mobile OS has.

</comment><comment><USER46> Small correction: "Chrome is still open source" is incorrect. Chromium is open source. Chrome is closed source.

</comment><comment><USER47> Google is creating a walled garden just like any other company does. The article points to how they are making their shift towards an operating system that is similar to ios (in terms of lock in). Android may be an open-source platform but, on the majority of devices that compete at the top level, it becomes far from open source.

It's understandable why Google would lock people out of seeing the back end of their closed apps. But you have to look at what the long-term implications of them slowly removing support for ASOP apps are. As Google continually pushes out fantastic products that tie in so well to the mobile experience, why would anyone/developer want to have/develop [for] anything else. As this power grows, Google can strong-arm phone manufactures to develop hardware/features/etc to work with what they are developing. They have to sign contractual agreements to get the top version of Android and are then locked in to keep up the good terms. Google is outsourcing the hardware manufacturing to other companies and ensuring that if a user wants a good phone, they will be using their services.

Many people here are claiming any company can leave Google's garden like Amazon did. While some companies may be able to do that, I'm struggling to think of a one with the technological background, money to invest, and callousness for risk who are willing to try. Amazon has a huge assortment of media that it can toss at its users who use their hardware. Other companies don't have a differentiating factor or the software development to be able to make a truly competitive product to drive people away from Google supported Android. Just look at how much Microsoft, a software giant, is struggling to gain any shred of market share.

No executive in any reasonable company is going to propose to invest billions in order to squeeze into the highly competitive mobile OS market. It's a huge risk that only a startup could swallow, and yet few startups could even raise the money required to topple the Google supported android market.

What the future is starting to look like is the one Google was initially afraid of, that users were" faced a Draconian future, a future where…one company, one device, one carrier would be [the] only choice." As Google gains more power, the open source part that Android users love is going to slowly disappear. This may or may not happen, there are many variables that could prevent it, but it is a future that would bring Google the highest return and that is the goal of all market traded companies.

</comment><comment><USER48> google had a very good reason to move services outside AOSP, to update them without relying on carriers. they could release billing API v3 w/ 90% compatibility in day 1. this is how they could workaround fragmentation. as an android dev, i love being able to read framework source code for better design, performance and less bugs. that is all really matters imho.

<comment><USER7> for development yes, thats like providing a SDK. I can develop just fine on Windows phones and even iOS :) So basically, its not really all that opensource anymore, that's what most people mean.

<comment><USER48> it is not the same with providing an SDK. Well, if android was documented better, we would not need source code this much but most of the time, it requires checking the actual implementation to understand the whole picture. Probably it is the difference between being "just fine" to creating great things.

</comment></comment></comment><comment><USER49> I don't understand the point of this article especially the bit about being an evil genius by ways of making excellent best in business cross OS api's. Really? being competitive is being an evil genius? If amazon is willing it can open there api's to none FireOS apps they have the infrastructure and money to support it, but they don't.

As a user I'm happy that Google is making sure that I can hop device manufactures without loosing my apps or functionality, if everybody would roll out there own app store and removed Google's you would be locked in with the OEM. Now you can safely change to a different phone, also they don't mind you downloading the Google apps when using an alternative ROM.

Android is open source but does that mean that you are not aloud to make money of it by providing closed source apps and service, many open source companies do that. The work that went in to Android if freely available for competitors. Lots of kernel enchantments went back in to Linux and now you have Ubuntu touch and Firefox OS both based on the Android kernel which in turn is based on Linux, how cool is that.

</comment><comment><USER50> I once read an article in 2010 that criticized people for saying that Apple and iOS of the 2000s is like the Microsoft and Windows of the 90s. The article pointed out that Apple IS the Apple of the 90s and Google with its Android platform will become the Windows of the 90s. I think it's happening. In a few years Android is going to be as closed sourced as Windows, probably as ubiquitous, and most likely, just as prone to security issues.

It's already kind of like windows, no? It runs on hundreds if different devices. It's often bloated by OEM software that people hate. It's prone to security wholes. It's slow and clunky unless you run it on the latest hardware. It bends over backwards for compatibility sake. It's more and more closed sourced...

Android is Mobile windows of the 90s. I hope Ubuntu Mobile will be successful.

<comment><USER51> Sorry, but some of the things you wrote are about perception, not reality.

What does "prone to security issues" mean? And compared to what? When we compare iOS and Android, iOS had 304 vulnerabilities in 2007-2013 (294 in 2009-2013), while Android had 29 in 2009-2013[1]. That's order of magnitude difference, yet Android is blamed to be prone to security holes.

Also what does "clunky unless you run it on the latest hardware"? All systems are slow, when you run new system on old hardware. You cannot bend physics there. Ever used iOS4 on iPhone 3G? iOS7 on iPhone4? Or why there is no WP8 update for WP7 phones? These are exactly the same reasons.

Even the APIs in Play Services, as described in the article, are exactly marked as "google, not android". You project has to explicitly include Google APIs, it is not enough to target Android. Every Android developer knows that.

[1] [http://www.cvedetails.com/product/15556/](http://www.cvedetails.com/product/15556/) and [http://www.cvedetails.com/product/19997/](http://www.cvedetails.com/product/19997/)

<comment> wes-exp Vulnerability numbers alone do not accurately convey the mobile security landscape. To start with, even if those mean something, we must consider that Android devices tend to lag behind in terms of receiving OS updates. By contrast, iOS devices tend to be quickly updated.

It is widely known that iOS is far more secure in the practical sense for the average user. Report: [http://www.f-secure.com/static/doc/labs_global/Research/Mobi...](http://www.f-secure.com/static/doc/labs_global/Research/Mobile%20Threat%20Report%20Q4%202012.pdf)

<comment><USER51> Few centuries ago, it was widely known, that the Earth is flat. Just because something is widely believed, does not mean, that it is true. I would prefer to believe hard, cold numbers, or analysis like this: [http://qz.com/131436/contrary-to-what-youve-heard-android- is...](http://qz.com/131436/contrary-to-what-youve-heard-android-is-almost- impenetrable-to-malware/)

That F-Secure report describes legitimate applications that could be potentialy used as a malware (e.g. just like Wireshark on desktops) or trojans. What happens with trojans is described in the link above.

Also note, that it is in F-Secure's interest to cause scare, it is good for their business. They are not interested in people rationaly thinking about presented issues.

</comment></comment></comment></comment><comment><USER52> Nothing wrong with what Google is doing. Google is essentially a consumer (and enterprise) cloud services company that is looking to commoditize (read open source/sell at cost) all other parts of the stack. That includes open-sourcing Chrome/Android, selling Chromecast/Google Fiber at cost.

</comment><comment><USER53> Claiming that Google is "controlling open source" by working in-house on it's own Android applications is just really bizarre.

</comment><comment><USER54> So, every Samsung phone effectively comes with three versions of the main apps - the AOSP version, the Google Play version, and Samsung's bloatware?

This seems like a terrible situation for users. Can someone with a Samsung smartphone confirm this?

If this is the case, how are the apps organized when you first buy the phone - are they all in one big apps list?

<comment><USER55> Samsung devices ship with two versions, remember that while Samsung can't opt out of the Google apps, they're free to remove any AOSP app they'd like.

In fact, I've had AOSP apps disappear from my Cyanogen Mod ROM when I installed gapps, although I don't know if that was due to being overwritten or just part of the install script.

</comment></comment><comment><USER56> Wow, I've heard that HN is often pro google, but this thread makes it blatantly clear.

</comment><comment><USER57> I know this is potentially dangerous in the future (I worry more about NSA having direct access to all the phones in the world through Google), but in terms of user experience, I welcome this. In order to have an ecosystem that is "as unified and standardized as possible" you need to have one company controlling it, and the vision behind it. Too many companies pulling in too many directions is not that good.

Here's a different perspective:

[http://techtainian.com/news/2013/10/20/editorial-how- kitkat-...](http://techtainian.com/news/2013/10/20/editorial-how-kitkat-will- reclaim-android-and-unify-holo-with-kennedy)

</comment><comment><USER58> If AOSP is open source and Google updates let's say the location services, why can't anyone start a similar project for AOSP and have it funded (like by Apache or Mozilla)?

It seems that the main problem is the gatekeepers who manufacture phones.

<comment><USER7> Mozilla makes Firefox OS. They don't have the resources to also fix Android and what not, I think. Apache takes a few projects under its wing but they don't provide the developers, and thus many of their projects are stalling.

</comment></comment><comment><USER59> IMHO, the unfair part is the following:

"Since the Kindle OS counts as an incompatible version of Android, no major OEM is allowed to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list."

Google Apps and APIs are fine and good, but I don't think any company should dictate to an OEM what products they can make for other companies.

</comment><comment><USER20> I'm surprised that there's no mention of Tizen, Samsung and Intel's project and supposedly the former's Plan B to ditch Android altogether. With the same TouchWiz skin both Samsung's Android and Tizen, and with both OS's able to run Android apps, the plan would be to swap out the underlying OS without the users noticing.

</comment><comment><USER60> Sometimes businesses take measures to increase profits at the expense of their users. However, preventing fragmentation of Android seems to be both in both Google's interests and the users. Only certain competitors could mind. Also, why should Google do all the work of creating an operating system and not get anything in return?

</comment><comment> at-fates-hands As much as the Android people hate the Apple people, Android is doing the same thing Windows and Apple have been doing for years - trying to shoe horn people into THEIR walled in garden.

This is the future of smartphones. You pick a phone and by doing so, you pick the walled garden you're going to most comfortable playing in, pure and simple.

</comment><comment><USER61> I think Google's malicious intent is being over-exaggerated. It could simply be that they don't have enough resources to maintain old code. As to them creating closed-source apps, well, Google knows which side their bread is buttered on :) Anything that makes money for them is closed source.

</comment><comment><USER62> I'm curious to know if there are any internal google project of porting all the Google play API on iOS (either on Objective-C , or using a cross-platform language such as mono develop, which would make more sense).

</comment><comment><USER63> Why don't they (potential competitors) write an open source app based on openstreetmap? Their mapping data is usually on par, often even superior to that of Google. Plus, its free (in both senses of the word).

</comment><comment><USER64> Nothing good can come out of Amazon or Samsung influencing or controlling Android. If those companies were in control, we'd still be in the tech ice ages where the phone companies control our devices.

</comment><comment><USER65> So I guess the sign to look out for is Samsung licensing the Amazon APIs?

<comment><USER66> That would be interesting: an Amazon-Samsung software-hardware partnership.

</comment></comment><comment><USER67> This is an excellent piece of tech journalism and thank you for the journalist for examining each aspect of Google's strategy so thoroughly.

</comment><comment><USER68> As a Google shareholder, this article warms the cockles of my heart. Why should Amazon be able to get all the Android improvements that Google creates?

</comment><comment><USER69> I don't see how making closed source apps is "Controlling open source"

</comment><comment><USER70> By any means necessary? So they'd murder to control the source?

</comment><comment><USER29> Open always wins, until it conflicts with your business interests. "Open" used to be the oft-repeated advantage over iOS in the early days, I wonder if that will slip away from the narrative like "SD card slots", "removable batteries", and "real keyboard" did.

<comment><USER71> History doesn't really support this. Even Linux had to get some corporate backing (initially Red Hat, Suse, and the like), and later Canonical and others before it really took off.

Open source has proven to be a long term survivor, but not a winner.

<comment><USER17> Open source is most definitely winning in infrastructure, high performance computing, servers, etc...

Ask IBM or Oracle if Linux is losing...

<comment><USER71> You're conflating the reasons though...would Linux be winning in those areas without big corporate $$$?

<comment><USER17> Does it matter? Corporations adopted Linux because of it's openness, and Linux is winning in those areas because of corporations who adopted it because of....

Open doesn't mean 'hobbyist', it merely refers to the freedoms enabled by the code's license...

<comment><USER71> They adapted it because it was cheaper, not because it was open. Now, open frequently _tends_ to be cheaper, but not always, it isn't an inherent quality of openness.

<comment><USER17> IBM and Oracle both have in-house operating systems (AIX, z/OS, Solaris), and are both big enough that they have, for all practical purposes, unlimited resources.

Yet both use and push Linux, IBM uses SUSE Enterprise, and Oracle forked Red Hat's OS...

I really doubt either cared about whatever marginal cost they may or may not save. Linux's openness is kind of like natural selection - good features live on, bad ones die.

Open source does make better software (everything else being equal of course).

</comment></comment></comment></comment></comment></comment></comment><comment><USER72> Should read more like "Google has an Iron grip on Google Apps (Gapps)" \- Not Android. Android is the OS, not the Google service based apps.

<comment><USER73> Isn't the whle point of the article that it's getting harder and harder to get the OS without being tied to Gapps? Which would justify the title?

<comment><USER74> The Android platform is open source under Apache/BSD/MIT licenses -- it's no harder to get that than it ever has been (not hard at all). Look at products like Kindle Fire for examples of "uses Android without Google Apps".

<comment><USER73> Yes you can easily just download it. But that's not exactly what the article is about. It's about why OEMs don't just download it and put it on there as such, but instead seem to get tied to Google Apps.</comment></comment></comment></comment>


Go Creeping In - <AUTHOR> https://www.tbray.org/ongoing/When/201x/2019/06/12/Go-Creeping-In <comment><USER2> I am not a Go programmer, but every time there is a discussion about Go I want to link to the article on "Language Design in the Service of Software Engineering": [https://talks.golang.org/2012/splash.article](https://talks.golang.org/2012/splash.article)

It explains so many of Go's design decisions and why it is the way it is (e.g. why something like gofmt/gofix is among the best things about the language); I wish there were similar articles on the design decisions behind more languages.

The first point in this (OP) post is also explained by the same philosophy: as far as Readability / "I can pop open almost any .go file and [can] understand it pretty quick" goes, it is a powerful thing to be able to navigate to pretty much any team's code and not only understand their code but also be able to focus on what's specific to that code rather than on idiosyncratic stylistic differences. In other languages this is done with a lot of adherence to the style guide; if Go tries to make it even easier, this would make sense.

<comment><USER3> At my current job, most of the backend code is divided in two separate groups. One uses Java while another is built with Go. Both have teams have very good reasons to choose what they did and both languages are serving their purpose pretty well but one of the major issues with the Java team I've seen is how discussion there is around styling the code. Most PRs have some comments about some styling and it gets a bit worse every time a new engineer joins the team. I think what you pointed about Go is one of it's best features if not the best.

<comment><USER4> The Java team could use EditorConfig, CheckStyle, FindBugs, ErrorProne, or other tools to enforce team rules similar to how the Go team uses tools like gofmt.

<comment><USER5> I think the part here is that there aren't tools "like" gofmt - there is only gofmt. Other tools wrap it, but there's no choice (and bikeshedding) to make.

<comment><USER4> If the team puts in place a code formatter/linter tool there won't be bikeshedding for them either. If they're happy to let google format their Go code they can let google format their Java code too: [https://github.com/google/google-java- format](https://github.com/google/google-java-format)

<comment><USER6> We had a "discussion" on which formatter/linter to use for a different language. There were 2 choices and I bet we spend 300 man hours on nonsense. Everyone had to have their say.

You can decide TO use a linter, but then you just get to argue about which linter...

<comment><USER4> The fact that there are multiple linter tools shouldn't paralyze a group of people for 300 man hours. The Go ecosystem will eventually have choices too. For instance, I think there are a couple of different protobuf implementations for Go already.

<comment><USER7> It shouldn't but it does. See Wadler's Law:

[https://wiki.haskell.org/Wadler's_Law](https://wiki.haskell.org/Wadler's_Law)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> The most important property of Go for me is that the language is not red/blue. [1]

This enables I/O interfaces to be truly universal, covering just about everything from files on disk, to pipes, to in-memory buffers, to sockets. This feature facilitates a style of, for lack of a better word, _generic_ programming that is hard to come by in other systems.

I find basically any other language or platform except Go lacking and unpleasant in this regard, due to the viral nature of asynchronous functions, which never disappears entirely, no matter how much syntactic sugar is sprinkled on top of it.

Things like mismatch between event reactors or asynchronous frameworks do not exist in Go. Interfaces Just Work, and the entire ecosystem uses them.

[1] [http://journal.stuffwithstuff.com/2015/02/01/what-color- is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your- function/)

<comment><USER9> I wish I understood what problems people solve day in and day out such that they need to call IO in the middle of Dijkstra's algorithm. Most "business logic" ought be pure functions over persistent data structures with no IO other than the occasional logging. At the last possible moment, 5% of the code wires in IO in some boilerplaty way. Is that sufficiently pervasive to worry about it?

<comment><USER10> > what problems people solve that they need to call IO in the middle of > Dijkstra's algorithm.

I worked on several problems of this nature at Twitter in 2012. Hopefully there's a better way to solve them in 2019...prolly not, but maybe.

say you want to find the median of the number of followers a person on twitter has. so that should be easy - make 1 dataframe with follower count of each bloke and call median() - well, there's some 300,000,000 blokes, so not that easy :) You have to make a dataframe via ETL - reading & writing to disk 100s of times, loading a few thousand users each time, distributed median computation. so a silly sub-second median query took 2 months to code up & debug & ran for a few hours due to so much IO.

another much harder problem - you want to find the median number of hops between one user & another. so now you have 300m x 300m tuples as your result - where & how to store them is in itself a monstrous challenge. but how the heck do you even compute the result ? you read in one tweet from john to steve, so that's 1 hop from john to steve & viceversa. you then read a second tweet from steve to mary, so that's 1 hop from steve to mary & viceversa, 2 hops from john to mary & viceversa. in this manner you read 100s of billions of tweets & keep updating hopcount. somewhere in there john sends mary a tweet - oh fuck now the hopcount is 1, not 2. this will then change lots of other hopcounts. in theory there are nice graph algos for this sort of thing. but in reality, your data is billions of tweets constantly increasing, stored in distributed compute clusters across the planet & just getting a handle on all this can be a 6 month project for some lucky scientist who got to work on this.

<comment><USER11> > I worked on several problems of this nature at Twitter in 2012. Hopefully > there's a better way to solve them in 2019...prolly not, but maybe.

Okay, so Twitter has scale. To a first, second and third order engineering approximation-- _nobody else does_.

If you are a mere mortal writing practically anything, pull it all into memory, operate on it to create another copy, destroy the original copy (or let GC kill it).

Embedded programmers _might_ get a pass on this given limited memory (32K RAM)--but that same kind of attitude is getting more and more essential as you start getting Big/Little core mixes on the same chip.

Computers are mind-bogglingly powerful.

I have been completely stunned at how many transactions Nginix+Django+PostgreSQL can actually handle before you need to start thinking about "scaling".

</comment></comment></comment></comment><comment><USER12> Programmers who write CLI apps/network-services tend to love Go. Programmers who love mutable, imperative programming love Go. Programmers who find the CSP model a natural fit for asynchronous programming love Go. Programmers who want the stdlib to contain what they need for 80% of use-cases love Go. Programmers who love checking `if err != nil` in every statement love Go.

Programmers who write re-usable libraries (eventually) come to hate Go. Programmers who leverage Sequences/Streams, immutability and functional programming tend to hate Go. Programmers who prefer exceptions or railway- result types for error handling also tend to hate Go. Programmers who desire tight control over performance and memory management will obviously hate Go.

In my _personal_ opinion, the Go language is handicapped to claim simplicity. However, the Go standard library is amazing for productivity. If Go the language, didn't come with its stdlib and wasn't pushed by Google, you wouldn't have so many Go fans.

<comment><USER13> > Programmers who leverage Sequences/Streams, immutability and functional > programming tend to hate Go.

I dunno, applying the Reader/Writer pattern to other objects in order to get sequences & streams works pretty well in Go.

> If Go the language, didn't come with its stdlib and wasn't pushed by Google, > you wouldn't have so many Go fans.

I think the latter part is very true. Go had the very good fortune to be a Pike tool put out by Google back when, 'hey, Google are producing this!' was a _good_ thing.

I like Go, but I also like Plan 9 — and it never took off. Neither did Newsqueak or Alef. But Go did, in large part, I think, due to Google's positive reputation a decade ago.

<comment><USER14> The Reader/Writer interfaces are beautiful in their simplicity, but they're only useful if you want to stream raw, non-Go data. If you want to iterate over a slice or a channel, basically as soon as your data is fit into Go datastructures you don't have a simple and beautiful pattern for working with them as a flow of data.

<comment><USER13> You can always implement a FooReader, which iterates over a flow of Foo objects (which might, for example, be items in a slice or channel). We do this all the time. It is, as you note, quite simple and I think elegant too.

<comment><USER12> Yes, I have done this, but I was talking more about streams that I can splice, filter, map, join, pair, slice, window, buffer, groupby, scan, skip, take, switch, zip, reduce, etc.

Not really possible without generics, lambdas and a good core of functional routines.

Once you get used to this and the speed, productivity and elegance with which problems can be solved, using Golang feels a bit primitive and painful. The same Go code is usually 5x-10x longer.

</comment></comment></comment></comment></comment><comment><USER15> That's a trend I witnessed first hand while working as dev for a bank. Old Java code slowly being phased out for Go. Which to me seemed like madness at the time due to lack of generics but it turned out to be fine, just needed a different mindset. This often resulted in a much shorter edit-compile-run loop and halved the hardware requirements, specially memory.

These days I'm not even surprised when new clients demand Go in my current consulting firm.

I think there are "better" languages than Go but they also come with their own tradeoffs and from what I've seen, to many it seems Go is preffered after weighting in.

<comment><USER16> This is interesting. At the Banks was this driven by internal staff, or contractors?

I'm considering contracting, any particular banks that you thought were more competent?

<comment><USER15> In my case the Go adoption was spearheaded by a team lead from their staff.

As for what banks are more competent or dare I say modern, it can vary wildly even in the same bank depending on what piece of software each team works on. From my experience banks are (understandably) resistant to change so you might have a hard time finding greenfield projects there. In general, I'd say go for banks only if you're interested in quick money over career development. It can be soul crushing at times.

<comment><USER17> Disclaimer: At a very large US bank.

Seconding the assessment. We have pockets of everything from legacy mainframe you've probably never heard of (no, not every mainframe is an IBM) to cutting edge cloud/docker/devops/agile/etc. Just depends on where you can be plugged in.

</comment></comment></comment></comment><comment><USER18> _It's amazing — amazing I say — how little generics are missed._

Ooof. I've just spent about 3 days debugging Go code that was copypasted x N, with minor (incorrect) modifications. Rewriting it with generics would have been about 30-min job and made it much more maintainable in the future.

<comment><USER19> Yeah, I wish more people would accept that there are clear tradeoffs between different type systems.

The tradeoff in Go seems to work reasonably well for services that doesn't want, or need, to handle complex application domain as fluently as concurrency. Essentially it works well for network/systems level code, and anything that looks like that.

But for code that is more of an encoding on an application/service domain, the lack if generics hinders reasoning more than it helps. There you have no use for the fancy concurrency stuff, it has to be abstracted away for the domain experts to be able to be productive. There are, usually, also enough code that global readability become less helpful, and unambiguous contracts/types across systems becomes moreso.

The latter case is massively helped by any way to enforce contracts over methods and types, as long as refactoring tools can reason over it. Nevertheless I do believe that locally (in methods/functions) a well behaved type inference and IDE tooling is better than extremely verbose type statements that I then make the IDE hide from me!

To me these are clearly different scenarios, but apparently not to most people, or these discussions would rarely occur, but we would have discussions about the characteristics of languages making them suitable for any specific task.

After all, for every solution there exists a possible language where the solution for a particular problem is part of the language, trivially making it the best language for that problem.

Also trivially, there exists a best language for me, personally, to solve any problem. This is the hypothetical language which encodes and compensates for my individual perceptual and cognitive bias.

Now, in a large enough enterprise, the most important contracts, and hence generics, might be expressed in the outward facing interfaces, and thus making them mostly redundant in a single service. Sharing implementations becomes less important at this scale, as it creates problems on it own. Hiring and onboarding masses of juniors are commonly a problem here.

Hence, except for networking/systems styled solutions, Go might also be well suited for very large organizations with endless hiring needs, and a desire to look more modern.

<comment><USER20> >Essentially it works well for network/systems level code, and anything that looks like that.

You can also see this in the testing story. Go is very focused on unit testing which makes sense when you are one cog in a giant machine. But if you're writing something standalone the friction to write end to end integration tests is what turned me off.

</comment></comment></comment><comment><USER21> I have had much success with Go for the past 5 years.

Simplicity is by far the most powerful feature. If I have to hire someone right out of school, they can pickup the language very quickly.

If a team member leaves the company, I can still read and understand the code they wrote.

Over a long term horizon, the features of Go make it easier to maintain the software written with it.

<comment><USER22> This is the killer feature of Go, and it's what so many who clamor for various features-of-other-languages miss.

Go is designed for simplicity. It is easy to write, but more importantly is easy to understand, even far in the future. For a given problem, _n_ programmers will generally coalesce on a small number of possible Go implementations, whereas other languages will often yield _n_ divergent solutions.

I've had Go solutions that I built years ago that I can get into and maintain in seconds, even when I hadn't touched Go in months.

Go isn't my primary tooling (my life today is mostly Swift), but as a comparison where a language has gone awry I'd point to C# -- as Microsoft has tried to incorporate whatever cool thing every other language has added, C# projects have often turned into write-only projects where the original author barely can grok their code a month later, and everyone shrugs and says "rewrite it" when confronted with another programmer's C# code. Rust is much the same.

<comment><USER23> Can you give an example of Rust incorporating "whatever cool thing every other language has added"?

I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.

<comment><USER22> That statement was clearly in reference to C#, which evolved from a beautifully concise language to now being a mishmash of every other style of programming (including the abomination that is LINQ).

Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone.

This is where our egos step forward and we announce that it's No Problem For Me, but we've all experienced a situation where we've leveraged a powerful language to do some amazing things, and then a month later it is a gruelling, headache inducing experience trying to figure out what is doing what, where, so we announce that we'll just rewrite the whole thing.

<comment><USER23> > Rust, though, suffers from being too clever, making it a language in which > you can make concise, powerful solutions, but it can making grokking the > code difficult, inefficient and error prone.

Can you explain _specifically_ how Rust is supposedly too clever?

<comment><USER22> With all due respect, I don't think you're in a position to have a unbiased perspective on this, and I am certain I'm never going to convince you.

But I'll leave it that there have been countless "Rust is too difficult" links for you to find on Google, many of which have been posted on here. And _invariably_ when we discuss Rust the conversation goes like this-

"why is it so complex to do [some simple thing]?"

"Oh well Rust is a _System Programming Language_ , and it's doing important things in important ways"

"Okay, but I'm not building an OS, I'm just..."

[chest puffing, ego's appear, etc]

"Well _I_ certainly have no problem with it..."

<comment><USER23> I still can't figure out exactly what design decisions you disagree with, but it sounds like you're objecting to the lack of GC or memory safety. There are some applications for which GC is not appropriate. Maybe you don't work on any of those applications. That's fine, but that's very different from saying Rust is overly complicated.

<comment><USER24> I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Its interesting to see what languages become the backbone of different industries. Here in Houston, .NET rules, and I have seen a huge shift towards .NET core and cross platform. Im in the middle of a big build out right now, and we have begun building .NET core services that don't use IIS for our service layer.

<comment><USER26> Here in Germany, at enterprise level it is pretty much .NET, Java, C++ and Web, while most mobile apps tend to focus either on mobile Web or hybrid solutions (Xamarin, Ionic, C++ with native views).

Everything else are just small campings.

</comment></comment><comment><USER27> I just don't think Go has a place in new code. I know Googlers (who shall remain unnamed to protect the innocent, and politics at that company can kill your career) who joined the Go fandom because its their company's language, their department was C++ or Google-flavored Java heavy (arguably, a Java style worse than 'normal' Java or Android's dialect), and it was their only way out...

However, when they were exposed to Rust, a lot of them converted to Rust, and now write Rust for Google on internal apps that need performance but safety, especially during concurrency. Others were exposed to Kotlin (especially due to the Android guys), and are championing that as a replacement for Google- flavored Java inside the company, since the JVM is also very sane when it comes to large scale safety during concurrency.

So yeah, if I was writing brand new highly concurrent coroutines-like code, I'd skip Go and Goroutines, and go straight to Kotlin and Akka (not written in Kotlin, but very natural to use with Kotlin), since I end up with the power of the JVM, the elegance of Kotlin's syntax, and the Erlang Actors brought by Akka.

And for those who have never used Erlang, learn it once, write something highly concurrent in it, and you'll learn to distaste almost every other language's faulty concurrency idioms almost immediately. Without the Erlang actors model, you're not going to be writing fault tolerant concurrent systems; just like "all languages converge until they become LISP", all concurrency systems converge until they become an Erlang actor model.

<comment><USER28> I'm personally not a big fan of Go due to the weak type system, with lack of generics as the main offender. And as a result, the ubiquitous `interface{}` pattern, stringly typed annotations, ...

BUT Go offers simplicity, incredibly easy concurrency, decent performance, a good standard library for networking/http services, very quick compile times and a stricter type system than many other languages like Python/PHP.

For many teams, especially coming from more dynamic languages, Go fills a sweet spot of performance, concurrency, type safety and ease of use.

I love Rust, but it is much more complex, boilerplate heavy, adds more friction, is harder to learn, and concurrency is much harder to get right, even with the upcoming async/await feature. Not to mention the immature ecosystem, that will still need years of catching up to achieve parity with Go.

Kotlin is also a great language, but has it's own downsides. You need to learn and understand Java (due to the many Java dependencies that you will pull in), there often will be a mismatch between Java libraries and idiomatic Kotlin code, concurrency is harder than in Go, and the JVM is a much more complex beast then the minimally tunable Go runtime.

Go definitely has a place, even though it often wouldn't be my own first choice.

<comment><USER29> > the ubiquitous `interface{}` pattern

I'm totally biased because I've worked on and with go for a decade, including reviewing all sorts of Go we write at Google, but I just don't get this criticism. It's just not something I see in the code bases I work on. I admit that I may be working on different kinds of programs to what some others do, and I don't want to deny anyone their legitimate experiences, but my personal experience has been that this is rarely a thing, if ever.

<comment><USER28> It can be found in many libraries in the ecosystem, and is common enough in the standard library.

The lack of generics just severely restricts the expressiveness of the type system.

I think the best way to work around this is use of code generation, which is a great tool for internal, controlled environments, but very cumbersome for open source libraries.

<comment><USER29> I don't see much, if any, generated Go code at Google. Not to say that it doesn't happen but it's not on my radar.

<comment><USER30> Aren't http or grpc apis autogenerated? You'd be crazy not to use a generator for those.

</comment></comment></comment></comment></comment></comment><comment><USER31> I'm still super annoyed that the solution to "dynamically resolving dependencies is a PITA" became "just make a monolithic app and pray for no external dependencies/conflicts".

Windows figured this out ages ago. You ship DLLs with your app, you keep them in the same directory, and run your app wherever, but update it incrementally. Now your user doesn't need to download a 120MB file every time there is a one- line change.

Wrapping this pattern in a ZIP file that can be executed directly (another Windows-ism) basically gives you everything you want from a static app, but adds the ability to inspect and patch components. Why does nobody use this method?

<comment><USER32> You can send out binary patches / deltas though?

</comment></comment><comment><USER33> The number of Go-haters (for lack of a better term) in here is astounding, to me.

If you don't want to see Go in new code, then _don 't use Go in new code._ There's nothing wrong with this point of view, by the way, (even though it confuses me a bit.)

If you won't use Go because of its current lack of generics, that's a perfectly valid point! Don't use Go. I don't mind AT ALL.

If you don't like Go for whatever reason, then _don 't use it._ Nothing at all wrong with that position.

What I am astounded by is the apparent notion in here that "others need to be made aware my position and brought into agreement with me" \- not quoting anyone, just trying to cite a feeling MANY of the comments here are giving me.

Maybe it's the HN culture to do this, or the culture of comment sections in general, I don't know.

<comment><USER34> I'm pretty sure the people that say they won't use go for new code won't use go for new code. Not sure what your point is.

Go (like Rust) is not particularly popular ourside the wider HN/SV community.

<comment><USER35> What's SV?

<comment><USER36> I guess it is Silicon Valley.

</comment></comment></comment></comment><comment><USER37> I use Go to solve problems. I don't solve _all_ problems with Go.

It works well enough, and the people I work with can collaborate in it easily enough.

I think that sometimes the (younger?) HN/SV crowd forgets that there are a lot of coders out there doing good work that don't need The Penultimate Best Tool. We just need a tool that works.

</comment><comment><USER38> It's amazing to see more and more finding Go. For a lot of us it's been almost a decade since we started using it. Back then for me it was the perfect blend between C and ruby. Today I believe it's the language of distributed systems and the cloud. I personally think Go ends up with majority marketshare for all cloud native systems and its already going in that direction with the core tools like docker, kubernetes, etcd, grpc all using it. By extension of that I believe a signifcant number of backend systems and services in the cloud will also predominantly be Go based.

This doesn't rule out other languages, its merely an indicator of a trend we've seen time and time again related to platforms. Windows, Linux, Android, etc. Every platform has a dominant language. Other newer up and comers like typescript, rust, swift, kotlin, etc have their place but for their respective platforms.

Go's adoption will accelerate in the next decade but you'll also find it disappear into the background as development as a whole levels up beyond the languages of today.

Only us millenials and older generations will speak of it. The next generation will be preoccupied with an entirely different model of programming.

<comment><USER39> And what model of programming do you suggest it might be? ;-D

<comment><USER40> Training AIs. I strongly believe this will be an occupation class in the future.

</comment></comment></comment><comment><USER41> Ah, the sweet smell of language wars in the morning.

Seriously, though, I wonder how much of golang adoption is due to it being a shiny new thing relative to Java and how much is due to it actually solving a problem. Bray outlines several areas where golang functionally outperforms Java (deadlocks, truly WORA).

I have used golang a bit and found it ok. Because of my background I'd prefer to write code in a dynamic language but I get that there are times when you need to have better performance, and you may want that without the baggage of the JVM.

<comment><USER39> I didn't find the article all that convincing. Just a general FOMO smell, and not much substance to back it up. Nothing deep.

</comment></comment><comment><USER42> Go is awesome programming language, since it is simple, readable and provides good tooling - code verification (vet), code formatting, testing, benchmarking, tracing, race detector, profiling - out of the box.

Go encourages writing simple straightforward code without complex abstractions. This improves programmers' productivity, which allows writing raw practical code instead of spending time on theoretical design patterns, inheritance hierarchy, generics, fancy algorithms, monads, "zero-cost" abstractions (with high mental cost), borrow checking, etc.

That's why we could write fast time series database in Go from scratch in less than a year - [https://github.com/VictoriaMetrics/VictoriaMetrics/](https://github.com/VictoriaMetrics/VictoriaMetrics/) .

</comment><comment><USER43> I can't help but feel that JS, Go and Rust will really carve out a lot of development that is currently in Java, and eventually a lot of C# as well. Java is a lion's share in corporate dev, and C# is similar, stronger in some regions/industries.

JS has already gained some traction via MEAN stack (though not a fan of Angular, and can do without Mongo). Go has started gaining traction, and I feel that once the Async/Await support cements in an LTS release of Rust, it's use will grow substantially as well.

Frankly, it's an interesting time to be a developer, and largely the past decade has been far more interesting than my first in software. I also think there's still room for improvement.

</comment><comment><USER44> I'm not experienced enough to give a proper critique of go, but I can say that as a non-cs major learning to code, I found go wonderful to work with. Type system is good enough to catch errors and understand code at a glance, yet not overly cumbersome. The language syntax strikes the right balance of verbosity. The only thing I don't like is the way errors are handled.

</comment><comment><USER45> I'm curious as to the thoughts of people here on C#. It's in the same Java/Go space, and .Net Core serms awesome on Linux.

<comment><USER46> Maybe you should turn this into an Ask post. I'm curious too.

<comment><USER45> Ask HN: What are your thoughts on C# on Linux? - [https://news.ycombinator.com/item?id=20212649](https://news.ycombinator.com/item?id=20212649)

Done!

</comment></comment></comment><comment><USER47> I like Go a lot. I just wish there was as much support in Go for machine learning as there is in Python.

At the moment, I feel like the whole "Python is the second best language for every problem" makes it the default choice for a lot of people.

<comment><USER48> I wrote a lot of (and still occasionally maintain) a library called golearn [1] which tried to bring first-class support for the "traditional" ML algorithms, but it seems that Go's compiler and toolchain just don't optimise well enough for Go to be very competitive on performance for that application. That's not a criticism of Go, it's just that C/C++/FORTRAN have decades of optimising compiler support and most competing solutions are Python sugar over a nest of such C/C++/FORTRAN libraries. Go's also concurrent, which is nice, but we found cases where being too concurrent also cost performance for most people. I'm still optimistic that Go has a place in ML, but it's probably not right now.

[1] [https://github.com/sjwitworth/golearn](https://github.com/sjwitworth/golearn)

<comment><USER47> I do wonder if bridging to a good matrix/tensor library would be sufficient (as it is in Python).

I'm aware of the interesting work happening in Swift/Tensorflow and was wondering what the equivalent in Go would look like.

<comment><USER49> Have a look at gorgonia.

[https://github.com/gorgonia/gorgonia](https://github.com/gorgonia/gorgonia)

<comment><USER50> To add to that, while Gorgonia's Tensor ([https://github.com/gorgonia/tensor](https://github.com/gorgonia/tensor)) library is fairly mature, plenty of work can still be done. Gorgonia proper too has plenty of work to be done on improving the various VMs. Last, there is greenfield work to be done in making Gorgonia user friendlier

</comment></comment></comment></comment></comment><comment><USER51> The rise of Kubernetes will likely enhance go's presence in devops.

<comment><USER52> How much Go do you have to write to use K8s though? So far all I've seen is YAML.

<comment><USER53> You don't need to write any unless your fixing bugs or contributing to the project (I'd say parent's comment still stands though).

<comment><USER52> > I'd say parent's comment still stands though

That people will appreciate Go because a tool is written in it? I'm dubious.

I use Kafka on a daily basis and read its source code with regularity to better understand its behaviour. and while I love what Kafka can handle, and how resilient it is, it doesn't enamour me more, or less, of Scala. What I love about Kafka has little to do with the language and everything to do with the architecture and design of the system.

Go is probably more readable than a lot of the legacy Scala in Kafka admittedly (although their new Scala and Java code is far more readable) which I guess could convince people to give it a try.

</comment></comment></comment></comment><comment><USER54> what happens at companies where there a LOT of math. Like fintech, AI, etc companies.

Are there equivalents of numpy,pandas, etc for go ?

what happens when you need to deploy models ?

<comment><USER55> You use something else. Go does well at shuffling bytes. It does ok at shuffling text. Once you leave those domains it starts to get abrasive pretty quick.

It turns out lots and lots of systems shuffle bytes & text so golang has a lot of room for adoption but for now modeling, business logic, math etc are all better done in other languages.

<comment><USER56> What are some language contenders for business logic?

<comment><USER57> At work for core domain modelling we use Haskell and for service layer code we use Go and Node. They are imho good fits for their respective problem domains.

<comment><USER53> How do "core domain modelling" and "service layer" communicate if you don't mind sharing?

<comment><USER57> If you mean operationally then it's via simple http apis, although we are in the process of moving to a fully serverless (ie. aws lambda) setup. If you mean the data exchange format then it's JSON.

</comment></comment></comment></comment></comment></comment><comment><USER58> Daily reminder that coroutines require a context switch.</comment>