Zero-downtime restarts in Go
github.com
github.com
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 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.
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.
The MySQL drivers there are tested and should work. If those were the ones you tried, I'd like to know.
I just filed an issue to make the above link more discoverable.
http://go-lang.cat-v.org/pure-go-libs
Next thing I did was ask on IRC, and there wasn't a consensus on which driver to use.
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.
Next year, who knows?
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.
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.
https://github.com/mortdeus/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.
https://code.google.com/p/go-wiki/wiki/GoUsers
And some of these companies are even writing/rewriting their spotlight core projects with Go.
https://code.google.com/p/go-wiki/wiki/SuccessStories
"Libraries cost time and money to produce"
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."
Have you tried reading https://code.google.com/p/go-wiki/wiki/SQLDrivers, or... perhaps considering using one of these, http://godoc.org/?q=sql
Maybe consider this which looks considerably up to date. https://github.com/go-sql-driver/mysql
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.
http://swtch.com/~rsc/go11.html
I mean sure there are alot of bugs to fix and alot more than can be done to improve go's performance, but this is true for all software in general.
The reason go is a good investment because it has alot of good investors investing in it.
> 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.
No, you just got hit with the typical Go activism reply when someone mentions issues with the language.
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.
I'm trying to see whether https://github.com/droundy/gotgo helps
Can you give any concrete code examples including a description what you would have liked differently?
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.
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.
http://code.google.com/p/vitess/wiki/ProjectGoals#Why_did_we...
> 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.
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.
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.
For what it's worth, I ended up using this one: github.com/ziutek/mymysql/mysql
That's not the drivers fault: https://code.google.com/p/go/issues/detail?id=4804
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're just looking for another language to get away from the cesspit that is Ruby, try Python.
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 :-)
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.