

Zero-downtime restarts in Go - neeee
https://github.com/rcrowley/goagain

======
lbarrow
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...](https://braintreepayments.com/braintrust/gotchas-irritants-
and-warts-in-go-web-development)).

Still -- as more and more libraries like this get released and stabilized, Go
will become an increasingly interesting option for developers.

~~~
mortdeus
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.

~~~
codexon
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.

~~~
epoxyhockey
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.

~~~
sigzero
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.

~~~
mortdeus
Go was built to solve problems like the ones faced at google. However, go can
solve just about any theoretical computational problem C can.

------
kkowalczyk
I run 3 websites written in Go
([http://blog.kowalczyk.info/article/uvw2/Thoughts-on-Go-
after...](http://blog.kowalczyk.info/article/uvw2/Thoughts-on-Go-after-
writing-3-websites.html))

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.

~~~
codexon
If you are running a paid app or making rapid changes your users will notice.

~~~
bickfordb
In these cases hopefully your business is real enough to be able to afford a
load balancer.

------
thibaut_barrere
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?

~~~
dsl
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.

~~~
thibaut_barrere
Do you mean you believe that people using Ruby are either Ruby committers, or
people with only pure Ruby experience?

If this is true, I think you'll miss some great candidates, to be honest.

Things I did before, for instance, include:

\- writing real-time 2D/3D rendering engines, mixing C++, TurboPascal, Asm

\- low-level assembly code, writing keyboard hardware interrupt handlers, TSR,
video-cards tweaking etc

\- porting C-libraries from Solaris to Windows

\- writing a full GUI toolkit

\- writing 2D games

\- wrapping C and C++ libraries into .Net

\- writing a cluster of satellite images processing with PVM

Etc (apart from using Java, .Net, Ruby, CoffeeScript etc).

To make my point clear: the good rubyists I know have a _lot_ of past
experience, similar to this.

Talking about "cesspit" is not giving good signals about how you consider
other technical choices, either :-)

------
daakus
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>

------
justinhj
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?

------
voidlogic
Cool, it seems like this package might work very well with this one:
<https://news.ycombinator.com/item?id=5443107>

------
davidw
I wonder how long it will be before Go gets "enough" of Erlang to make it a
suitable replacement for most people who need/want the Erlang goodies.

~~~
bwooce
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.

------
the_mitsuhiko
What novel concept :P

