We used this for a while at Braintree. It works great for Unicorn-style restarts, but it doesn't ensure that the server shuts down gracefully.
So while you'll have uninterrupted connectivity, if you don't ensure that your server shuts down gracefully, you'll still drop the requests that the old process is servicing when the restart is triggered. We wrote a library called manners for managing the graceful shutdown of a single server: https://github.com/braintree/manners. When used in conjunction with manners, GoAgain provides zero-downtime restarts without any dropped requests.
(Manners is still under development, so make sure you understand it before using it.)
We had an interesting experience with Go. We ended up deciding the language was not a great fit for our needs right now, in part because the community is still pretty immature. (You can read about our experiences here: https://braintreepayments.com/braintrust/gotchas-irritants-a...).
Still -- as more and more libraries like this get released and stabilized, Go will become an increasingly interesting option for developers.
Go is only ever going to be as useful as the community works towards making it useful. We are trying our best to implement all the boilerplate code and solve all of Go's short comings.
Go is a very young programming language and unfortunately there are alot of cases where we have to implement pkg foo, bar, baz, because pkg quux depends on them. There are going to be many places where things break at this stage in Go's life, however that shouldnt discourage using Go for real world projects, because many of yesterday's bug end up being debugged and patched today. Go is a great investment for your company, and I hope you and your team reconsider using go for your projects after go 1.1 comes out.
http://tip.golang.org/doc/go1.1
If you guys need help, feel free to join us in #go-nuts on freenode's irc server. IMHO, The best feature of go is, arguably, the helpful evangelist-like gopher community hanging out in IRC. We wouldnt mind helping you guys with your issues, but you have to help us help you.
I don't think this is a reasonable demand for startups or even medium sized businesses.
Libraries cost time and money to produce, and if you are relying on free volunteers, development will either be slow or buggy and likely both.
I remember when I tried to look into a MySQL library last month. The first one I tried wouldn't even compile. The 2nd one threw a connection error not when I issued the dial function, but when I tried a query on a fake IP.
If you want Go to succeed, get Google to start funding it more or get used to having it grow organically like every other language.
Oddly enough, I tried THREE MySQL libraries last week, and every one of them seemed to work perfectly, allowing me the luxury to choose which of the libraries I most preferred the syntax of.
For what it's worth, I ended up using this one: github.com/ziutek/mymysql/mysql
I'm curious if we can draw any comparisons to what Google is doing with Go and what Sun Microsystems did with Java, as far as a corporation supporting development of a language goes?
How many resources did Sun allocate to developing and supporting Java?
EDIT: One of the things that excites me about Go as opposed to something like Ruby on Rails or node.js (V8, aside) is that Google is behind it.
Google is committed to Go. We already run a bunch of stuff written in Go, and continue to throw more engineers at improving the Go ecosystem inside the company. But Google's relationship with Go is not the same as Sun's was with Java.
Sun made Java a core part of their business strategy. With Go, Google isn't getting into the language business, but rather supporting an ambitious open source project that suits Google's needs internally.
As an open source project, Go has been quite successful so far. While the main driving force comes from the team at Google (we are employed to do this, after all), there are now more committers to the Go core from outside Google than within.
Sun pushed Java for everything and everyone one. Go was built to solve problems at Google. If they solve your problem, cool, but that isn't (or wasn't) the goal.
Its best to think of google as the main sponsor of Go. Kinda like how apple is the main sponsor of LLVM. Go is a completely opensource commit-reviewed driven project. Developers from other companies other than Google have commit permissions and there arent any situations where go team works in house on the language for 6 months then throws all their commits over the wall.
Also go is at heart a language specification. It is designed so that anybody can create their own go compiler, and as long as they honor the go spec and standard library, all go code should theoretically compile with your custom compiler.
There are already a few other compilers in development out there. Gccgo is a go compiler with gcc as a bankend. llgo is similar except its frontend is written in go and uses cgo to wrap the LLVM C wrapper api to generate llvm bitcode.
Im starting to reimplementing the official go gc and cc compilers written in go for my port of plan9's userland shell commands called goblin.
In my opinion this is the core difference between java and go. Oracle believes they own java and will fight against projects derived from java, for example the lawsuit against dalvik. Google on the other hand is open to projects like the ones I mentioned above.
"I don't think this is a reasonable demand for startups or even medium sized businesses."
It was a recommendation. Go is a great investment, and while it may not have a "huge" market share, many of the most influential tech company's in silicon valley are starting to use Go.
Time yes, Money no. Developers may charge money to produce software, however there are lots of software projects out there that were written by developers who worked for free. Does a painter always paint with the intention to sell his/her work at a gallery showing? Maybe they just want to create something for other people to experience.
I view all software from this perspective, and I give alot of my time working on go boilerplate libraries and other opensource projects for free because I want to help empower developers to create real world solutions to real world problems without the nuance of having to "invent the wheel before being able to engineer a new automobile".
"and if you are relying on free volunteers, development will either be slow or buggy and likely both."
Pass.
"I remember when I tried to look into a MySQL library last month. The first one I tried wouldn't even compile. The 2nd one threw a connection error not when I issued the dial function, but when I tried a query on a fake IP."
Your experience last month with Go may very well be irrelevant now. Ive been using Go for about a year now, and many things have changed within go's development ecosystem within that time period.
If you arent willing/capable of contributing to go by committing code, thats perfectly fine. However, atleast make sure that your issues with the language are actually still relevant before you discourage other developers from exploring the language themselves.
"If you want Go to succeed"
As if its likely to fail? Go has already successfully satisfied the language designer's desires that motivated the project's creation. They want to create a language that makes their programming environment more enjoyable and efficient when developing software at a scale Google operates at.
Unless some language comes along that is exceptionally better at solving the problems Go was design to solve, Go will remain a successful programming language for those who use it.
"get Google to start funding it more"
Are you kidding me? Google has some of the most well respected engineers in computational history working full time on Go. Google cant just walk into best buy and hire geek squad to work on Go. We are trying to reduce go's overall source code complexity so that we can not only maintain the code, but ensure we dont introduce bad language design mechanics as apart of the programming environment. We want to avoid the situation, years down the road., where we are faced with having to make a decision to either cope with a bad language mechanic or deal with it by introducing backwards incompatible changes that break gopher's code. Both options suck, and the only good option is to avoid the situation entirely by making sure we make the best design choices.
"or get used to having it grow organically like every other language."
Most languages dont grow organically. Most either grow all mutated and exponentially complex to adapt to changes in technology, or development either slows down or stops growing completely because the majority developers who used the language, moved on to something .
Go on the other hand does grow organically, atleast it has so far.
Everyday the project matures and issues we are frustrated with right now could be a faux problem because its already been fixed in go tip and you just need to rebuild the compiler.
> The reason go is a good investment because it has alot of good investors investing in it.
A lot of good investors invested in MongoDB.
> Time yes, Money no. Developers may charge money to produce software, however there are lots of software projects out there that were written by developers who worked for free.
Have you ever been in a startup before? Spending months reinventing the wheel while competitors are working on business logic is a great way to set yourself permanently behind.
> As if its likely to fail? Go has already successfully satisfied the language designer's desires that motivated the project's creation.
Besides Vitess, what other high profile usage is there at Google? Not to mention they offloaded part of the implementation to Memcache because Go wasn't good enough.
> Are you kidding me? Google has some of the most well respected engineers in computational history working full time on Go.
You don't need Turing award winners to flesh out solid libraries. Go doesn't even have a precise GC and still won't have one by 1.1.
Issues? What issues? Most complaints about Go are really just "it doesn't contain my favorite language feature", "I heard the GC isn't even precise so it must suck", "it's too immature", "I couldn't get this library to work within 10 minutes so Go sucks", etc. pp., but people are simply unable to point to any actual pain points that hinder productive use of Go.
That being said, I still have the feeling that having to rewrite a lot of dummy boilerplate code because of lack of generic collections hinders my productivity.
I completely understand that introducing that in the language it's a pandora box, etc etc (not only because of compiler's complexity and compilation speed).
But still, I have to find a way around that, being DRY has obvious advantages (although depending too much on obscure magic can be a problem); it's not just a random language feature from my favorite language.
With your logic, the same argument could be applied to PHP.
The problem is that Go simply doesn't solve anything new. If Go contains your favorite language features but not mine, then why should I bother to use or hype it?
If you want lightweight concurrency with GC you could have gone with Scala, Erlang, or Haskell.
> Besides Vitess, what other high profile usage is there at Google?
The piece of software that runs on dl.google.com, which serves millions of Chrome updates every day, is written in Go. The problem is: you're asking for Go success stories at Google, even though most of Google's internals will never be published. Why don't you just take a closer look at other companies' success stories and acknowledge them?
> Not to mention they offloaded part of the implementation to Memcache because Go wasn't good enough.
Huh, what? Using memcached means the technology you use isn't good enough, or what are you trying to suggest? Don't forget that the author of memcached is a core Go developer at Google, so I'd say they know what they're doing.
> Go’s existing mark-and-sweep garbage collector is sub-optimal for systems that use large amounts of static memory (like caches). In the case of vtocc, this would be the row cache. To alleviate this, we intend to use memcache for the time being.
For a self-described systems level language this is ridiculous. I would like Go to replace C++ and Java, but false optimism won't make this happen.
> Time yes, Money no. Developers may charge money to produce software, however there are lots of software projects out there that were written by developers who worked for free.
If the software was developed on company time, it maps to the developer's salary per hour times the amount of hours taken to develop it.
> Are you kidding me? Google has some of the most well respected engineers in computational history working full time on Go.
The same can be said for Wave, Reader and many other projects.
Go is awesome, and I'm glad to see people are having success with it. I wouldn't worry too much about the haters. Every successful project attracts them (they wouldn't spend their time trolling unsuccessful ones).
I think that any startup that chooses Go will attract people who are passionate about their work. Paul Graham wrote about this in connection with Python, but I think it's equally true in this case. That kind of advantage is worth more than having a few extra libraries, most (although not all) of which can be whipped up in a week or two anyway.
Those are clearly not Facebook scale servers but for majority of people: you don't need this or any other such solution.
Here's what I do for deployment. I have a fabric script that:
- copies the new executable to the server
- kills currently running executable
- starts the new executable
The worst that can happen is that a few connections will get dropped and that's perfectly fine 99.9% of websites. You don't control internet so the users will get broken connections all the time for reasons you can't eliminate. They shrug and hit reload button.
Complicating things to avoid few seconds of downtime was not worth it for me and rationally, probably not worth it for most.
If you deployed Go in production, I'd love reading about that since I'm having a closer look at it now (coming from Ruby). Is there a more widely used option currently?
Looking at the source, and having looked at how nginx does it, this looks like a pretty straightforward implementation with no real frills. I imagine anyone doing this in production with Go already has just rolled their own solution not much unlike this (doing this for some pet projects of mine has been on my TODO for a few weeks, never got around to it though).
Unless you are a committer to Ruby now, or plan to invest in learning more powerful languages, Go probably isn't a good choice. I run a pure Go shop and we generally look for people with hardcore C (not C++ or C#) or systems/kernel backgrounds or at least one open source Go library under their belt.
If you're just looking for another language to get away from the cesspit that is Ruby, try Python.
I built something similar which additionally provides graceful termination of established connections as well as systemd socket activation to (optionally) provide lazy startup of servers: https://github.com/daaku/go.grace
The documentation is very light so I had a look through the source code. Is the purpose of this to remotely restart a go app (that presumably has been updated and deployed) via TCP whilst keeping the TCP connection alive, or is there more to it?
There appear to be some philosophical differences that mean this won't occur.
Specifically the "let it fail" aspect of OTP, which begets supervisor hierarchies and the consequent lack of exception handling required.
This has been brought up before and dismissed (not the unix way perhaps? I forget), and supervisors have been implemented in go by others from Erlang backgrounds. It's just not quite the same as being built in.
The way goroutines are not linked to their parents or children is related to this. It's a conscious design decision, but I am still adjusting my style to it.
So while you'll have uninterrupted connectivity, if you don't ensure that your server shuts down gracefully, you'll still drop the requests that the old process is servicing when the restart is triggered. We wrote a library called manners for managing the graceful shutdown of a single server: https://github.com/braintree/manners. When used in conjunction with manners, GoAgain provides zero-downtime restarts without any dropped requests.
(Manners is still under development, so make sure you understand it before using it.)
We had an interesting experience with Go. We ended up deciding the language was not a great fit for our needs right now, in part because the community is still pretty immature. (You can read about our experiences here: https://braintreepayments.com/braintrust/gotchas-irritants-a...).
Still -- as more and more libraries like this get released and stabilized, Go will become an increasingly interesting option for developers.