<p>As someone who does most of my programming in Python, I can see significant advantages to moving some projects to Go. I could really benefit from concurrency, better performance and static binary deployment.</p>
<p>However, I am worried about relying on a language which is dominated by a single company. Unlike the community-led development of Python, the lead developers of Go all seem to be employed by Google to work on the language. Does it concern you that Go is managed by a single company rather than an independent "foundation"?</p>
<p>Also, if Go is run "by Google", is it run "for Google"? How willing have the developers been to accommodate the needs of users outside Google?</p>
<p>Finally, do you think it is possible that Google will drop support for Go, as they have for many other projects? If that were to happen, how would you expect the language to fare?</p>
<hr/>**评论：**<br/><br/>stupidworkalt2: <pre><p>Go has almost 900 contributors, most of which are not Google employees. <a href="https://golang.org/CONTRIBUTORS" rel="nofollow">https://golang.org/CONTRIBUTORS</a></p>
<p>Thus far contribution acceptance seems to be much more merit based than politically motivated. Google does push for support for their initiatives (such as HTTP/2) but I haven't seen any evidence of a contribution being declined for non-technical means.</p></pre>rogerdpack: <pre><p>What percent of contributions are from google employees vs. not anyone?</p></pre>datf: <pre><ul>
<li>850 names in that list.</li>
<li>139 of which have an @google.com email.</li>
</ul>
<p>If you add people that have @golang.org to @google.com the number is 180.</p></pre>dlsniper: <pre><p>Given how all new infrastructure tools tend to be created in Go, I'd say you are safe. Go is also open-source and should G drop it, it can be maintained by the community. However since it's already a part of their infrastructure, I'd say you are safe.</p></pre>bakery2k: <pre><blockquote>
<p>all new infrastructure tools tend to be created in Go</p>
</blockquote>
<p>Interesting - do you have some examples of such tools?</p></pre>koffiezet: <pre><p>In addition to <a href="/u/dlsniper" rel="nofollow">/u/dlsniper</a>'s list: caddy, influxdb, heka, all new Hashicorp stuff (vault, packer, consul, serf, nomad, otto, terraform), the grafana backend, etcd, fleet, prometheus, ...</p>
<p>Ops in general jumped on Go since it filled a gap and allows for faster applications with lower memory footprint and no dependency mess compared to things written in the classic scripting languages that were used before (Python and Ruby mainly, before that Perl). It also allows for much more complex and time-sensitive applications - good example here is InfluxDB.</p></pre>DeedleFake: <pre><p><a href="https://github.com/sony" rel="nofollow">Sony</a>, too. </p>
<p>Edit: And <a href="https://github.com/microsoft?utf8=%E2%9C%93&query=go" rel="nofollow">Microsoft</a>.</p></pre>dlsniper: <pre><p>Even Bower is using Go, id that counts for something...</p></pre>google_you: <pre><blockquote>
<p>Bower</p>
</blockquote>
<p>What is it? <a href="https://github.com/bower" rel="nofollow">https://github.com/bower</a> ?</p></pre>joushou: <pre><blockquote>
<p><a href="https://github.com/bower" rel="nofollow">https://github.com/bower</a></p>
</blockquote>
<p>Yeah, but the Go is in their backend, which was previously som node.js thing that couldn't cope with the load.</p></pre>Tacticus: <pre><p>Also traefik (similar to docker but connects to etcd\consul etc)</p></pre>FrenchDonkey: <pre><p>traefik is freaking awesome !</p></pre>dlsniper: <pre><p>Docker, Kubernetes, Pivotal uses them, Heroku, WeaveWorks, but I'm not a substitute for google, check it yourself...</p></pre>sickmate: <pre><p>Also Amazon's ECS agent.</p></pre>dlsniper: <pre><p>And the CLI agent on the EC2 instances: <a href="https://github.com/aws/amazon-ecs-cli" rel="nofollow">https://github.com/aws/amazon-ecs-cli</a> (does this make the biggest deployment of Go in the world then?)</p></pre>Bromlife: <pre><p>Also Canonical.</p></pre>sadlil: <pre><p>docker, kubernetes, gitlfs for github....</p></pre>twotwotwo: <pre><p>Managing versions of packages is one place Go's weirdness directly mirrors Google's--there's globally just one copy of a given library in Google's master codebase, and relatedly the go tool initially shipped without the built-in version-awareness that some languages' package managers have. The community has built ways to deal (look at 'vendoring', tools like gb). Google and Go are also both weird for using static binaries heavily, but the world has generally liked that aspect of Go, except when now and then someone gets annoyed at the 'Hello Word' binary size (heh).</p>
<p>But if you're living in Google's world, that's not <em>entirely</em> a bad thing. The stdlib has the quality of something that's been through a good code review process. (The APIs are consistent except a few legacy things from early Go dev, and you'll find most source readable when you're curious about how they did something or some detail of behavior. I encourage following the links to source from godoc, or browsing in your go/src/.) Their priorities, even when they're not quite yours or mine, at least more often relate to things that directly help ship reliable, maintainable software, not just proving ideas somebody had. The tools in distro (fmt, doc, test, profiles, race checker, tracing) and even a lot of third-party things (static checks!) reflect that attitude too.</p>
<p>I'd love someone to contradict me with their positive experiences, but I <em>haven't</em> seen a fantastic way to use Go to very quickly get to your initial launch of a database-backed Web app with a complicated schema. Django and the ecosystem around it are <em>great</em> for time-to-launch of stuff like that. On the other hand, Python/Django cause you some pain when the app gets big (I know; we manage that pain daily at work). I think of using Go rather than Python as more like building with steel than wood. That probably offends Python, Go, wood, and steel enthusiasts all in one go, but what I'm trying to say is the Go project is a bit slower and more expensive to build but the product seems pretty solid and scalable after. Like wood and steel, either can make sense depending on the situation.</p>
<p>Like dlsniper said, Google's using too much Go to just drop it--Kubernetes is one big public project, but things like the download server you use to get copies of Chrome, YouTube's sharding MySQL proxy, a data-compressing proxy Chrome Mobile can use, etc. are in Go. Lots of smaller companies outside depend on it, too, which is a good sign for community support.</p></pre>rr1pp3rr: <pre><p>I'm a big fan of both Go and Python. Been using Python 10 years professionally and Go since 1.0. If you look at my history of posts you'll see that I'm a big fan of Go, and I am active in the open source community.</p>
<p>I think about this question a lot. I have been working at an internet startup for the past 5 years, and was the first engineer hired there. In that time, we've grown to mid size company.</p>
<p>Our original stack was Python + celery. It was awesome, made some mistakes, but it was pretty slick. We decided to do a rebuild a couple of years back, and we chose a Microservice architecture. This wasn't just because of tech reasons, the industry we're in changed so much in the past 5 years it made sense to start fresh. We use Go quite a bit and its been great. Our go projects are some of the most solid services at the company. Fast, small, and very few bugs. I attribute a large amount of that to the go language itself.</p>
<p>That being said, I think about what I would do if I got this opportunity again to start a companies new stack. And if I did, I would undoubtedly choose Python and django. The speed of getting a system up and running with that tooling just can't be beat. </p>
<p>However, I would have very stringent guidelines on how the different django apps would be built. No dependencies between apps. They all have to talk through some RPC. That way, when I inevitability want to decouple them, I can. Golang is tailor made for Microservices like that, and it would be on my short list of languages for those services almost every time.</p>
<p>I think about this shit way too much. I should start a crappy blog or something where I lambast people who do shit the way I don't do shit. To, you know, REALLY participate in the internet.</p>
<p>Sorry formatting - on phone.</p></pre>joushou: <pre><p>A few things:
1) Dependency management is not a Go specific problem.</p>
<p>Global library version: Go (GOPATH), Python, npm --global, C/C++/... using dynamic linking.
Vendoring: Go, npm
Project-specific global: Go (with GOPATH managers), mvn, virtualenv'd Python, C/C++/... with project-local libraries.</p>
<p>There is no good solution. All of the above have their own distinct problems.</p>
<p>2) The love for static binaries is completely normal. <a href="http://harmful.cat-v.org/software/dynamic-linking/" rel="nofollow">Dynamic linking is an awful thing</a>. It also moves dependency management to execution time, rather than leaving it a task for compilation time. The problems of dynamic linking and execution-time dependency management is one of the reasons that Docker is popular.</p></pre>JRMWarfare: <pre><p>Your frustration with using Go with complex database schemas used to be my chief concern with the language - it's not easy to implement a series of models quickly in just the core language, but</p>
<p><a href="https://www.github.com/knq/xo" rel="nofollow">this</a> is developed and maintained by fellow gophers. </p>
<p>I actually found it via this subreddit, and it's actively maintained and quite useful. It takes your database schema and generates the core code you need to get things up and running.</p></pre>leidegre: <pre><p>I think Go is being developed by a couple of very experienced programmers that are drawing from lessons learned at Google. Go is not just a programming language and for that reason I don't think it will be killed of anytime soon. It's also gaining ground and chipping away at other communities. </p>
<p>Inherent in the design of Go is a systems programming paradigm akin to what we have in C and C++ with a focus on performance but with memory safety. Something which is very important if you care about security. Which you should.</p>
<p>Go might be sponsored by Google but it is open source and you can contribute to the project even if you don't work at Google.</p>
<p>Not all ideas are welcome though and that's simply because the nature of Go. The goal of the project isn't to be the next C++ or C# the goal is simplicity.</p></pre>I_am_toxic_af_x10: <pre><p>server programming...</p></pre>thepciet: <pre><p>Personally I am well prepared to use Go indefinitely - I feel safe assuming most standard library functions are well implemented, and if something breaks I know enough to fix most anything with enough time. Having the language source code is powerful, although I should spend time learning building the go tool before Google gets shut down.</p></pre>kaeshiwaza: <pre><p>What make me feel safe with Go is the design of simplicity and static typing. Even if Go is abandoned it will be easy to translate the code to an other language. Maybe easier than between py2 and py3 ;-) !
I'm more afraid of using frameworks or any dependencies.</p></pre>__crackers__: <pre><p>I find Python an interesting example of a community-led language to pick given the decade-long train wreck that is Python 3.</p>
<p>The main reason I picked up Go was because I came to the conclusion that it might be another decade or more till Python 3 gets fixed (if it ever does).</p></pre>rr1pp3rr: <pre><p>Can you explain a bit about what you think is horribly broken in python3?</p></pre>__crackers__: <pre><blockquote>
<p>horribly broken in python3</p>
</blockquote>
<p>I didn't say that, did I?</p>
<p>Wishlist to fix Py3:</p>
<ul>
<li>Default to UTF-8, not ASCII</li>
<li>Tag <code>str</code> objects that contain surrogate escapes and ensure the used codec is also stored on the object</li>
<li>Put back the rest of the Py2 <code>str</code> API into the <code>bytes</code> API</li>
</ul></pre>Uncaffeinated: <pre><p>The biggest dealbreaker for me is the poor pypy support.</p>
<p>But apart from that, I am annoyed that they changed a bunch of functions to lazy evaluation without adding any syntax to make eager evaluation easy. Writing list() everywhere is an awful lot of boilerplate.</p></pre>helinwang: <pre><p>IMHO python has too many problem to begin with (python3 trying to fix python2, then python3 need fixing). I think Fixing is not the cure. Choose a language that don't have many things need fixing. (golang)</p></pre>zinver: <pre><blockquote>
<p>given the decade-long train wreck that is Python 3.</p>
</blockquote>
<p>Python itself was a decade long train wreck before python 2.2 ...</p></pre>huydotnet: <pre><p>Rails was developed and most of the framework decisions made by single person (DHH) but it has many contributors. It's fine. </p>
<p>Microsoft .NET <em>was</em> developed and maintained by a single company for a decade. It's fine. </p>
<p>...(countless technologies here)...</p>
<p>I moved to Go from Node (and moved to Node from .NET few years ago) and I feel comfortable with it. Go can solve most of the problems I got. So I don't care much about will it be harmful or worth worrying if it was developed by a single company or a foundation. As long as they provide the best support for the developers and the community. </p>
<p>Try not to worry so much and start using it. Once you love it, there is no way back :)))</p></pre>hayzeus: <pre><p>Wait -- wasn't Guido also employed by Google? </p></pre>iends: <pre><p>He was, but I believe he works at Dropbox now.</p></pre>Tacticus: <pre><p>Yep. they are also a big go user. (they give great talks on go in production as well)</p></pre>interactiv_: <pre><p>The answer is no. Obviously Google uses Go, but plenty of googlers do not.</p></pre>I_am_toxic_af_x10: <pre><p>The language sources are open source, however google tightly controls the language. Those not in google must toe the line or be shunned. much of the core stuff is strictly controlled by google. All of the testing frameworks are google internal. The language spec and source is opensource but the actual project is under the thumb of google.</p>
<p>I doubt google will ever drop support for Go. Go is being groomed as a replacement for c/c++, java, python.</p></pre>villiger2: <pre><p>The other answers are all great, if you want a short answer though, it's essentially <code>yes</code> in response to your title.</p>
<p>Case in point: <a href="https://www.reddit.com/r/golang/comments/4pg58h/best_way_to_manage_dependencies/d4krtlg" rel="nofollow">https://www.reddit.com/r/golang/comments/4pg58h/best_way_to_manage_dependencies/d4krtlg</a></p></pre>IndianAlien: <pre><p>Erlang, which is one of the languages Go aimed to derive a lot of functionality from, was dropped by Ericsson. After that, it really took on a whole new life.</p></pre>jaetteintemer: <pre><p>I've never heard either that Go is modeled after Erlang OR that Ericsson dropped it..</p></pre>IndianAlien: <pre><p>The Ericsson part was from a video I watched by the creator of Erlang. There were some internal issues there and he was able to convince the company to open source it.</p></pre>LimEJET: <pre><p>The concurrency model is heavily influenced by Erlang.</p></pre>funny_falcon: <pre><p>No, consecutive predecessors of Go are Newsqueak, Alef and Limbo. All of them were developed with participation of Rob Pike. All of them had processes and channels (and <code>select</code> construction).</p>
<p>Newsqueak were developed in 1985 - an year before Erlang, and 15 years before Erlang became public.</p>
<p><a href="https://en.wikipedia.org/wiki/Newsqueak" rel="nofollow">https://en.wikipedia.org/wiki/Newsqueak</a>
<a href="https://en.wikipedia.org/wiki/Alef_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Alef_(programming_language)</a>
<a href="https://en.wikipedia.org/wiki/Limbo_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Limbo_(programming_language)</a>
<a href="https://ru.wikipedia.org/wiki/Go" rel="nofollow">https://ru.wikipedia.org/wiki/Go</a></p>
<p>Notice, that concurrency model is quite different:
- Erlang has "shared nothing" memory and single inbox per process (many-to-one message queue)
- Golang has shared memory, many-to-many message queues (channels), and one process may select from many queues using <code>select</code> construction.</p>
<p>Both Erlang and Newsqeak (Golang's grandpa) were influences by "C. A. R. Hoare's communicating sequential processes (CSP)", but in quite different ways.</p></pre>funny_falcon: <pre><p>Go has alternative history, and it has nothing with Erlang.</p>
<p>Look at Go's predecessors for:</p>
<p><a href="https://en.wikipedia.org/wiki/Newsqueak" rel="nofollow">https://en.wikipedia.org/wiki/Newsqueak</a> - 1985 year - was designed by Luca Cardelli and <em>Rob Pike</em>, its approach to concurrency was inspired by C. A. R. Hoare's communicating sequential processes (CSP). However, in Newsqueak, channels are first-class objects, with dynamic process creation and dynamic channel creation.</p>
<p><a href="https://en.wikipedia.org/wiki/Alef_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Alef_(programming_language)</a> - designed as part of the Plan 9 , implemented the channel-based concurrency model of Newsqueak. Also developed with participation of Rob Pike.</p>
<p><a href="https://en.wikipedia.org/wiki/Limbo_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Limbo_(programming_language)</a> - programming language for writing distributed systems and is the language used to write applications for the Inferno operating system. Also with Rob Pike as one of developers.
(modular programming,
concurrent programming,
strong type checking at compile- and run-time,
interprocess communication over typed channels,
automatic garbage collection,
simple abstract data types)</p>
<p>So, Golang is more Rob Pike's history :-)</p></pre>_ak: <pre><p>Go also draws quite a bit from the Wirth family of programming languages, in particular Oberon-2: <a href="https://talks.golang.org/2015/gophercon-goevolution.slide" rel="nofollow">https://talks.golang.org/2015/gophercon-goevolution.slide</a></p></pre>heyyyayea: <pre><p>Like most languages, the authors decide on what ultimately gets accommodated in the case of language features </p></pre>[deleted]: <pre><p>If you're looking for a stable environment then Go App Engine is not your solution because it's still in beta. At least it was the last time I looked. So be sure to make sure.</p>
<p>Also, regarding your question. When I've visited the help pages of <a href="https://golang.org/" rel="nofollow">https://golang.org/</a> in the past things rarely work the same on App Engine. The code fundamentals are mostly the same but grabbing code examples from that website and having them run on App Engine are two completely different stories.</p></pre>dlsniper: <pre><p>Go for AppEngine is not in beta for a while now</p></pre>[deleted]: <pre><p>I thought I saw it a couple months ago but apparently that happened in July of 2015. <a href="https://groups.google.com/forum/#!topic/google-appengine-go/as9wUqT77YU" rel="nofollow">https://groups.google.com/forum/#!topic/google-appengine-go/as9wUqT77YU</a></p>
<p>Hey do you know that Google Fonts has a new address? It's <a href="https://fonts.google.com/" rel="nofollow">https://fonts.google.com/</a></p></pre>[deleted]: <pre><p>How does this response get me -2 points? FUCK YOU.</p></pre>dgryski: <pre><p>My guess is because your comment is mostly inaccurate?</p></pre>[deleted]: <pre><p>So what I've experienced in the past with the content from the website is lie. It is not, you're wrong. And, you're barking up the wrong tree.</p></pre>dlsniper: <pre><p>Also this comment now draws more negative points which in turn make that be downvoted as well. Guess gophers don't like bad language... </p></pre>[deleted]: <pre><p>This is my last Reddit login. Good bye.</p></pre>
