Tip:
Highlight text to annotate it
X
ANDREW GERRAND: Good morning everyone, and welcome to the
session, Go In Production.
This morning I've invited four members of the Go community,
and people who use Go in their companies, in production
systems to talk to you about how they use Go, and their
experience with using Go.
And so without further ado, and the format of this panel
is that we'll have four short presentations from the
panelists, and then I'll open the floor to questions.
And we'll have about half an hour worth of questions.
During each of the slides, there will be a little link in
the bottom left corner, which will be to a
Google moderator link.
So if you want to enter questions there as you think
of them during the talks, that's also a good idea.
So without further ado, I'll invite my first panelist.
He believes that the world needs better software, and he
works at Canonical currently, where he
works on the Juju project.
And he's also built Landscape and the Storm ORM.
And as a Go contributer and a member of the Go community,
he's worked on the Go core and the Mango, MongoDB driver,
Gocheck, [INAUDIBLE], and others.
Please welcome Gustavo Neimeyer, thank you.
GUSTAVO NIEMEYER: Thanks, Andrew.
And thank you very much as well for the Go team for
inviting me to talk to you and have a chance to describe why
we believe Go is a better language for our workloads.
Juju, I'm going to quickly describe what problem we're
trying to solve.
And then I will describe how we're solving it, and then
I'll go and tell few bits about why Go is helping us in
those tasks.
So imagine you wanted to develop, to deploy a service
with a couple of, let's say a couple of softwares, right?
Either you have a database and your
application, for instance.
And you're doing that with a tool, sometimes with the help
of a tool, or by hand.
So it usually goes like that.
You've got a couple of machines.
You give them some names, and you develop some affection for
those machines.
And you put configuration files into those machines.
Those configuration files generally will have details
such as the IP address for your database, and information
for exposing that service and the deals to interconnect to
those machines.
If you think about that, what you're actually doing is that
you're creating a topology of services so that the things
communicate with each other.
But what's occurred to us, which is really interesting,
is that in most cases that topology is actually in the
administrator's head.
You don't have that in the system itself.
So this is all good, but then some issues started to occur.
For instance, it became a bit hard to give names.
Can you imagine, for instance, giving like 600,000 names in
the [INAUDIBLE]
morning?
It's a bit tragic as well, because things, when you start
to get a lot of resources, whatever those resources are,
even if just a few are failing, you start to get lots
of failures and you have to deal with those.
So the topology in that case becomes a little
bit complex as well.
It's harder to get things together.
It's hard to keep in your mind what's actually happening in
the system.
So this is really what we were after.
We wanted to see not only how to solve this problem, but how
to enable people to collaborate while doing so.
And to collaborate, you have to re-use, you have to
understand how to manage those resources.
This is what Juju is about.
When we were planning the system, we very much has the
use case in mind.
How can we implement that in a very straightforward workflow?
We think a little bit about it, as like a [INAUDIBLE]
services.
You basically, for instance, Juju bootstrap, it not only
deploys the service itself, but it deploys the servers
that run the service.
And then you deploy a couple of services, just so you know,
deployment application MongoDB for instance.
And it will actually get those systems running on a service,
on a machine being managed.
OK, but how do I tell the system that those two servers
are communicating?
We explicitly say add a relation between them.
And the bits that are composed, the services, the
charms, as we call them that compose the system, they have
knowledge about how to establish
that relation, right?
So since that knowledge is within the system you can
start to do tricks, like very easily add GNU new units.
You can add new bits to the system, and the system knows
how to interconnect those bits to the rest of the system.
Where is the topology in that case?
It is inside.
The system knows what's going on.
Those bits are reusable, they're independent, and they
are exchangeable so that people can deploy a better
MongoDB deploy bits of those systems, and everybody in the
community benefits from that.
So we're porting everything to Go.
It was originally made in Twisted, in Python with
Twisted, and we're porting the whole system to Go
for quite a bit now.
And we already have base work in production, such as the
database, the service, the services themselves are served
from, they're all running from Go.
So why are we doing that?
There are a few reasons.
One of them, for instance, is error checking.
One of the beautiful things about Juju, and the thing that
really attracts people is that it's kind of a
magic system, right?
You just type some commands, and whoah, I
have a service running.
But magic systems can also break magically.
This is a very sensitive subject, right?
We want things to be running.
We want people to not have to go after the issues
and the bugs then.
We want to reduce the chance at least.
It's going to happen, but we want to reduce the chance of
that happening.
Go gives us a very visual way to say here you have an error,
do something with it.
Another very interesting point for us was the fact that, for
instance, when we requested a watch from Zoo Keeper, which
is one of the systems we use in the back-end, we get two
futures back.
Each one of those futures, the first one gives us the data,
and the second one gives us notifications
once the data changes.
And that means that you basically have different paths
that your code has to deal with, right?
You have the first future that may fire, you have the second
one, and you have the path that is the function that is
currently executing.
But all of that is a single algorithm so we have to take
those three features and have to put them back into a single
logic that makes sense.
Go gives us a very straightforward path for that.
You can just say give me a watch, it can block until the
data comes back, and the channel actually gives you a
good way to wait for that information as well in line,
without having to go out.
I don't have time to go over each detail.
Changing a language for a project from one side to the
other is a very important decision.
There are many, many small bits that would take a full
talk to go over.
So this is basically what we're doing.
If you want more information, please, this is the URL.
Andrew, thank you.
ANDREW GERRAND: Thanks, Gustavo.
So my next speaker is one of the first engineers at Heroku,
and didn't respond to my request to send me a
biography, and is also a great guy.
Please welcome Keith Rarick.
KEITH RARICK: Thanks, Andrew.
I'd like to give you a quick story about one of the first
production systems that we used Go for at Heroku.
So first of all what's Heroku?
For those of you who haven't looked at it before, it's a
platform as a service for running primarily web
applications.
It started out just as Ruby on Rails, but these days you can
run just anything, including Go.
Right now we have about 1.9 million apps, and the company
itself has about 85 employees.
How Heroku works, just in a super short nutshell is each
app runs as a handful, one or more lightweight containers
that we call dynos.
And one of the most important pieces of Heroku is our HTTP
front end routing service.
It has to have a table of all the processes that are running
and where they are at any moment, so that it can handle
incoming user requests and send them to the right place.
And of course it changes whenever
processes start and stop.
For example, when a user scales up to more dynos.
Now not all of these 1.9 millio apps are actually
active at any moment, but a significant fraction are.
And of course it's changing all the time.
The way we've implemented this is we have a service to store
just the routing table.
It keeps the canonical copy of this table in a Postgres
database, and it was originally written in Ruby as
a RESTful HTTP sort of API in front of this database.
So whenever the Process Manager starts or stops a
process, it makes a call to this service
to update its record.
And then on the other side, whenever we start up a new
instance of the front end router, it connects into the
service, gets an initial JSON dump of the entire table, and
then after that, streaming updates.
So it saves in the sync.
So here's a picture of roughly what that looks like.
Things go in from the left and come out on the right.
And this works pretty great, especially because each front
end router has a complete copy of the table in memory, so it
can do fast look ups with no IPC or anything like that.
But there's a problem, and that's just that bootstrapping
a new instance of the front end router is
prohibitively slow.
And it turns out that that's just because of the process
generating, the Ruby process generating this
initial JSON dump.
So the guy who's working on this project, he had already
used Go for a couple of experiments on smaller things.
And he decided it might be worth taking a look to see if
it would help out in the situation.
So he decided he just wanted to make a drop in replacement
for the piece that generates the dump of the table and
sends out streaming updates.
And the nice thing was that he felt like he could just mess
around in an afternoon to get a good feel for whether or not
it would work out.
And in just a couple of hours, he had a working prototype
which was very encouraging, so we decided to go ahead and
make it into a real, clean it up and go through our normal
testing and staging procedures, and so we finally
deployed it to production, initially alongside the
existing Ruby process.
But here's the new picture with the Go piece in place.
And after running it for a while and getting
operationally comfortable with this new piece,
we flipped the switch.
This was some time ago, so that the Go process is now the
canonical one.
And honestly, it was pretty much a win all around.
First of all, it solved the initial problem that we set
out to solve with more than a 10x speedup
generating that dump.
And in addition to that, it's just the ops burden is
actually significantly less.
We can just take that single binary and throw it up on a
server, and it's easy to run, it's easy to manage.
And that's actually been sort of a recurring theme, sort of
overall at Heroku.
We've seen people sort of start to play around with Go a
little bit on some smaller things, or
just on a side project.
And then we've sort of adopted it for more and more things
actually in production.
So now we have a handful of systems running in production.
And there's several more on the way, in the pipeline.
Thanks.
ANDREW GERRAND: Thank you, Keith.
So my next guest has written software for heart devices,
video games, online dating systems and mobile apps.
Formally the CTO of OK Cupid, he's now
the founder of StatHat.
Please, oh.
I've done in the wrong order.
Oh my God.
Since I've introduced him, he can start.
Please welcome Patrick Crosby.
PATRICK CROSBY: We've all listened to our talks so much,
I probably could have done Evan's.
So StatHat as a service to track statistics in your
applications, you can add one line of
code and you get graphs.
You can track alerts and embed charts on your own site.
For example, say you have an online dating site.
One good metric to see if you have an effective site is to
track if the user gets a reply to their message.
So if you do something like change the matching algorithm
and the reply counts go up, then--
thank you--
then the matching algorithm has gotten better, and
StatHat's perfect for tracking something like this.
So this how you would track reply counts in the 15
different languages we support.
We have Go, Ruby, Python, and all the rest of these.
Once you add that one line, you get time charts showing
the value changing over time, histograms showing the
distribution of the data, and you can embed
charts in any site.
This is example from GitHub archive where they're tracking
every single GitHub event, and they show a StatHat chart on
their main site.
So you can track anything.
Here's a bunch of examples, but basically any number in
your code, any count, any event you can send to StatHat.
Almost everything in StatHat's written in Go.
We use a standard net HTTP package for our web and data
collection.
Our back-end all communicates over RPC, and we use a ton of
third party and standard packages.
We often get asked why we chose Go.
The main reasons is that it's fast.
Our services and request times are very low.
And it's also fast to develop, and because it's statically
typed, we don't have to write as many unit tests.
It's also very resource friendly.
Our server costs are much less than if we used
something like Rails.
It's an easy to deploy system, which I'll
talk about in a bit.
And it's also a fun language to spend your
time coding all day.
So a brief overview of our architecture.
So the stat we talked about before, the message reply
count comes in over HTTP to our data collection servers,
and it gets sent over RPC to the dataset services.
And the user interacting with the web service gets all the
components from the various RPC services, and then we have
some other Go applications that send
alerts and email reports.
Here's some details of the data collection service.
Once the stack comes in over HTTP, it gets put in the cache
right away, and we respond to the caller as soon as we can.
Then there's a Go routine that serializes this cache to disk
in case the server crashes, and another Go routine that
takes data out of the cache and puts it
in the update channel.
We then have a pool of hundreds of Go routines that
takes data out of the update channel and sends it over RPC
to the dataset services.
So deployment of Go applications is very easy, and
the main reason is the binaries are self-contained,
so there's no shared libraries, gems or
dependencies you have to worry about.
And the Go tool also downloads any third party packages for
you and installs them.
So basically if you can get your app to compile,
you can deploy it.
At StatHat, every time we do a get push it starts the
deployment process.
What this entails is it pulls all the code, runs all the
tests, and compiles all of our applications.
If all of that works, it then makes a bundle and adds all
the content resources.
And then we have a web service where we select the servers
that are supposed to receive this bundle, and just rsyncs
the bundle over and tells them that they have a new bundle
and they should restart anything.
And these servers don't have Go installed, they're just
basic Linux installations.
And this whole process to make the bundle takes about two
minutes, and it's 100,000 lines of code.
StatHat's an invitation only service, but if you go to
stathat.com/io2012 you can sign up without an invite, and
we also have some open source go code at stathat.com/src.
Thank you.
ANDREW GERRAND: Thanks, Patrick.
And I'll just jump back in my slides to the right spot.
I hope.
All right.
So my final guest is the lead engineer at Iron.io.
He was an early Go contributor and contributed to the FastCGI
and SMTP packages, and is now working on a book called Go In
Action from Manning publishing, please
welcome Evan Shaw.
EVAN SHAW: Hi, I'm just going to talk a little bit about
Iron.io and what we do, and how we're using Go.
So Iron.io builds cloud application services, that is
we build applications on top of cloud platforms like AWS
and Rackspace, maybe Google compute engine in the future.
And our main goal is to remove infrastructure worries.
So most companies have a small set of problems that they want
to focus on, and infrastructure is usually not
one of those problems.
And once we can remove these worries, we can enable smaller
teams to do bigger things, which is another
major goal of ours.
So the first product we came out with is called IronWorker.
It's a massively parallel worker platform.
So you upload your code or binary, and then start sending
us task data or payloads, and for each one of those you send
us, we'll queue a task, and then run it in
our pool server somewhere.
Our API for the service was originally written with Ruby
on Rails, but it wasn't really keeping up with demand, not
scaling how we wanted to.
So we wrote version two in Go, and that made it a lot faster.
We were able to take our roughly 30 Ruby servers and
condense them down to two Go servers.
And the second one is mostly for redundancy.
We have a couple other products written in Go.
One is IronMQ, a scalable message queue.
It runs underneath IronWorker and sends all your task data
to the runners.
And then IronCache, which is our latest product, it's a
distributed key value store.
Both of these have RESTful HTTP APIs and text protocol
support, being stock in the case of IronMQ and memchache
in the case of IronCache.
So here's just an illustration of the flow of data through
IronWorker and IronMQ.
You send it an HTTP request to go through the API, and then
we do a little processing there and put it on IronMQ.
And we have all these runners, which is what we call the
servers that actually run the job, polling tasks off of this
queue, and then running them.
So we serve a lot of HTTP requests in Iron.io using Go,
and the strategy that we use to serve those is generally by
composing HTTP handlers together into a chain.
So the first handler in the chain is typically
authentication.
We decide whether the request shold be able to continue, and
if not, it's unauthorized.
It if it is able to continue, it delegates to the next
handler in the chain.
Then we do something similar with statistics and usage.
So each one of these handlers has a very specific purpose,
and then it delegates onto the next handler until it gets to
the end, which does the validation of the request and
the database operations, and finally serves the response.
We don't use a lot of concurrency directly in our
applications, but that's really kind of a testament to
the good design of the Go libraries.
So the HTTP package automatically serves requests
in separate Go routines for us, we just have to make sure
that our handlers aren't sharing any state that's not
synchronized.
For text protocols, we do run separate Go routines for each
client, which doesn't require much communication.
But we automatically get Asynchronous I/O with that,
which is really awesome.
If we were writing this in node js we would have all
these callbacks while we waited for
operations to complete.
Or if we were writing it in C or C++ we would have to mess
with [? e-poll. ?]
It's just a big pain, but Go takes care of that for us in
the libraries, and we can just write code the way we
want to write it.
So one other place we use concurrency is as kind of an
optimization.
Sometimes you have these actions in the request,
response path that don't actually need to be completed
by the time you serve the response.
So we can move those into a separate Go routine.
Even less critical things can just have a dedicated go
routine that's kind of running in the background, gathering
up all this information and patching it together into one
request or one database update, or whatever it is.
So as an example of that first point, we have here an HTTP
handler that is getting a project ID and then updating
some statistics related to that project ID.
And this is a somewhat expensive operation,
noticeable if we keep it in the request response path.
So in the after code, we've moved that into an anonymous
function, put Go at the front, and made it into a call.
And now that code runs in a separate Go routine, and it
greatly reduces the latency of this request.
And this is something that's really cheap and easy to do,
and we've hardly even changed the code.
It looks almost the same.
So why do we use Go?
Well for one, it's fast.
It right not only runs fast, but it compiles quickly.
And I've worked on projects that take 45 minutes or an
hour to compile, and it's not fun.
It's still fairly expressive for a compiled, statically
typed language.
You don't tend to miss features from languages like
Ruby and Python.
It has a very rich standard library.
If you wanted to operate with formats like JSON or protocols
like HTTP and other languages, you might have to enlist in a
third party or non-standard library to get things done.
But almost everything we need is
built into the Go libraries.
It's not tied to a VM, which makes deployment really easy.
Go compiles static binaries with no dependencies, so you
just drop it on a server, run it, and that's it.
Nothing to really think about.
And finally, Go is awesome.
We have a lot of fun writing Go.
And so I hope if you were harboring any doubts about
using Go in production before this presentation, we've kind
of helped dispel those doubts.
Thank you.
ANDREW GERRAND: Thanks.
All right, so now I've invited to the others back on stage,
and if anybody would like to step up to the mic and ask
questions to our panelists, we'd be more than happy to
answer them.
First person to do so gets a Go [INAUDIBLE].
AUDIENCE: The guy from Heroku, one question.
Keith.
You're using Erlang as well at Heroku, and then what do you
use rather Erlang versus Go?
Because both languages do concurrency correctly, they're
one of the few languages that doesn't suck when it comes to
writing [? an array ?] of concurrent software and
reliable software.
KEITH RARICK: So how do we decide whether to use Erlang
or Go for any given project?
It's mostly up to whoever's working on the project.
The most well known thing that we have in Erlang is the
actual HTTP front end routers that I was mentioning earlier,
those are all written in Erlang.
I guess the biggest reason for those is that that project was
started before, I believe before Go even existed.
Certainly before it was publicly available.
And the team that maintains it, they like Erlang and they
don't feel like rewriting the whole thing.
But yeah, it's pretty much a personal choice.
I don't think we've started many new
projects in Erlang lately.
AUDIENCE: So why?
KEITH RARICK: Why?
Well, it's hard to find Erlang developers.
AUDIENCE: So Go might be a bit more approachable to
developers than compared to Erlang.
KEITH RARICK: Absolutely.
AUDIENCE: OK.
Thanks.
ANDREW GERRAND: Maybe you could say a little bit, maybe
each of you could say a little bit about your experience
bringing new developers up to speed with Go.
Leading on from there.
Someone.
EVAN SHAW: Okay, I'll Go.
Should I talk about hiring Go developers as well?
ANDREW GERRAND: Sure, whatever's most interesting.
EVAN SHAW: So since I've been working on Iron.io, we've had
I think a couple times where we've tried to hire Go
programmers, and we've been really
succesful in that so far.
We just put out a job notice on the [INAUDIBLE], and I
think within two days we had between [INAUDIBLE].
Some, not so good, but others very good, to the point where
we had to pool some time deciding who to hire.
So, no concern there.
We've also had a couple of developers who did not have
any Go experience, or did not have much Go experience come
in, and we found it very easy to get them up to speed on how
Go works, and [INAUDIBLE].
GUSTAVO NIEMEYER: After this talk, it's probably going to
get harder to find people.
KEITH RARICK: Yeah, I just wanted to add that something
that I've seen over and over again is talking with people
who are looking at Go or thinking about it, or maybe
they haven't even really looked at it carefully, but
you can talk to them about a new language, especially Go.
You can show them some examples, or you can say, oh,
look, it has all these great features, and it's easy to
deploy, and all this stuff.
But then if you can get someone to actually sit down
and write a page of code, spend 10 minutes actually
using it, that's a whole different story.
Then the light bulbs start going off, and then they are
going on, and then they really start to appreciate it.
But until that moment, that's usually a big turning point.
It's like people look at it, and they go, oh, that looks
interesting, it's pretty cool, and then they forget about it.
And then you do it again, and they give
you the same response.
But then when they actually start using it, then it's
pretty different.
GUSTAVO NIEMEYER: At Canonical, it's been quite a
ride as well.
Even more if you have a good
development body in the company.
It's not straightforward to just switch languages.
People are, sometimes they're passionate about the language.
Sometimes they're unwilling, they just don't have the time
to try something new.
I personally find people all over the place, but I share as
well Keith's feeling that when people do take the time to
experiment with it, and have an open mind about the
benefits of developing it, I do see people switching over
and getting closer to the language.
ANDREW GERRAND: Wanna take this question?
AUDIENCE: One of the common recurring themes we heard was
that we used to use Ruby, and so I was wondering what's the
Rails of Go, and what do you guys think about the packages,
and Ruby has a really huge community, and a lot of
different gems, and what do you guys think about the
community around Go?
ANDREW GERRAND: So that's kind of two questions there.
Maybe Patrick's best suited to answering about doing front
end development with Go, because I know his entire
stack is written in Go.
PATRICK CROSBY: We did have a prototype that was in Rails,
and we were worried about switching mainly because of
the plug-ins.
We didn't want to write user authentication again.
But then it actually took about an afternoon to write
the equivalent of [INAUDIBLE] in Go, and so we haven't been
spending our time on stuff like that.
But it's actually very easy.
The net HTTP package is great.
All you do is provide a function that handles a route,
and the template package is incredibly fast compared to
ERB or something.
So I wouldn't hesitate to try it.
And I don't think there's a Rails, there's a few other
third party packages for providing web services, but
the standard net HTTP works great for us.
ANDREW GERRAND: And do any of you want to
speak to the Go community?
The size of standard [INAUDIBLE]?
Well I know I know that at least a few people here are
active members of it.
GUSTAVO NIEMEYER: So the Go community, in a way it's like
we are the Go community as well.
ANDREW GERRAND: Not in total.
GUSTAVO NIEMEYER: Well, it's been growing, right?
The packages are just like any other language.
The quality of the packages are all over the place.
The number of packages, we have quite a few of those.
The core packages for our development, we pretty much
find what we want, or we develop the missing pieces
somewhat easily as well.
In terms of the question about Rails, or which platform to
use, I share Patrick's view as well.
The standard library is really good as well.
The HTTP package, for instance, it's unlike other
languages we've tried.
ANDREW GERRAND: And I think the man in the glasses of at
back there has a question.
AUDIENCE: Hi.
One of the questions I've heard from people when I
prophecise about Go is whether having a mark-and-sweep
garbage collector in a systems language makes any sense.
And I pushed back a little bit, obviously.
But I'm wondering if you guys have actually, using it in
production, can talk about whether having a garbage
collector in that language is an issue for you guys or not.
I'm just curious.
PATRICK CROSBY: It has not.
The only issue we had is there is a bug using 32-bit servers
with garbage collection.
But once we found out that there was a bug and switched
to 64-bit servers, we haven't had any problem with garbage
collection.
ANDREW GERRAND: And it's worth noting that that issue is
within a few weeks of being fixed entirely.
KEITH RARICK: One thing that I can say is we haven't yet used
Go for anything that's highly sensitive to latency, but
Heroku has a lot of pieces inside, a lot of different
components that were running in production, and honestly,
very few of them are actually that latency sensitive.
One example is something like again, this front end HTTP
router that handles user requests, that matters.
It matters that when a request comes in, it's not waiting for
a GC pause.
But relatively few pieces actually depend on that
particular kind of performance sensitivity.
So for most things that we're doing, it's batch operations,
it's background tasks, and it's not a big deal.
ANDREW GERRAND: But have you actually observed any GC
issues in what you're doing anyway?
KEITH RARICK: No.
GUSTAVO NIEMEYER: I think in our case it's similar.
We don't have workload with very low latency requirements.
And I also feel a little bit like the speed of the
language, the speed in which everything else executes, like
dwarfs the garbage collection problems we might have.
And I have to say as well, that in fact, from some
perspectives I've developed quite a few [INAUDIBLE]
extensions for Python to speed things up.
And while the reference counting could be faster, it
also creates a lot of issues in terms of leaks that are
really hard to find, and it's always a hunt going after
what's going on.
So in that regard, we have six stations as well in at least a
couple of our packages, and we haven't had any such issues.
So in that sense, the, garbage collector actually helps us.
ANDREW GERRAND: We'll take another question.
AUDIENCE: So all of the presentations said that while
Go is awesome, could you share, like, some of either
your favorite parts of it, or maybe things that your
developers, as you've been wrapping them up are like,
aha, that's so great.
KEITH RARICK: Gofmt.
That is my favorite part of Go.
ANDREW GERRAND: It's not a swear word.
Gofmt is the formatting tool that makes all Go code look
the same, ending all the style wars about why it's best in
[INAUDIBLE] placement and so on.
KEITH RARICK: More specifically, it's not just
that it exists, but that I am astounded at what a good job
the community has done at sort of adopting it and sticking
with it, and consistently using this tool, and never
having to worry about that stuff again is just, I mean
don't waste that time.
GUSTAVO NIEMEYER: So to kind of restate what I
said earlier again.
To me there's no single feature of Go that I find, oh
my God, this is so amazing, and I've never
seen anything similar.
Perhaps gofmt is a little bit unlike anything else.
But I think what's really fantastic about Go and unlike
anything else in my perspective is precisely the
fact of all the bits together, how they make sense.
EVAN SHAW: Yeah, I really agree with
what Gustavo was saying.
It's hard to really single out any one thing
that makes Go great.
But if you really force me to do it, I
would say the libraries.
I think of all the languages I've used, most libraries
[INAUDIBLE]
libraries I've seen.
[INAUDIBLE].
If you are curious about how something works internally,
it's very easy to dive in and start reading the code.
It's very accessible code, and good for
learning code as well.
KEITH RARICK: Yeah, I want to echo that too.
It's just systemic good design.
ANDREW GERRAND: Thanks.
Next question?
AUDIENCE: So I'm also using Go on production at SmugMug.
First of all I wanted to say thanks to everyone, and people
who are on the golang-nuts list, I read a lot of your
pots, and they're very helpful.
I mean, personally the thing for me that I like about Go
the most is it's impossible to get confused by most Go code.
I can show it to other people I work with.
It's always very straightforward, so I
appreciate the fact that there's been a tendency to
keep it simple.
So two questions I have for the panel.
One thing I noticed when I started building the proxy
server I wrote was sort of a lack of a
standard make like tool.
And there are a lot of them out there, and I'm just
wondering, and I just went with shell scripts because I
couldn't really see one that had traction.
Just wondering if there's a preference among the panel for
build tools automation.
PATRICK CROSBY: I think a lot of that's changed since Go 1.
Go install basically does everything for you.
We use that just go install StatHat basically.
GUSTAVO NIEMEYER: It's not even just the building part,
there's a good, consistent scheme in which
libraries are organized.
They're fetched from the network as well, so you can
do, like, goget and URL all with the command, and you get
the command running.
Even though it has dependencies, it has build
tools, so I find it pretty good.
ANDREW GERRAND: Yeah, but what they're referring to is, for
those who aren't familiar, is this Go tool that ships with
the Go tool chain, that's just called Go and there are
various verbs like gobuild, gotest, goinstall,
gofmt, and so on.
AUDIENCE: So my second question was if there's
anything from the libraries you think is missing that
you'd really like to see.
GUSTAVO NIEMEYER: There are certain things I'd like to see
better done, perhaps.
Like SSH package is one that is evolving, but it's complex
to get something that really works across all the cases in
a consistent and stable way.
So I appreciate the package.
I want to see it being polished over time.
ANDREW GERRAND: Thanks.
Take the next question.
AUDIENCE: So this is just from the Google moderator, which is
linked to from the screen.
So Jason asked, and you might have
covered this early, actually.
Can you talk about how long it would take to learn Go?
ANDREW GERRAND: How long does it take to learn Go?
KEITH RARICK: I know I referred to someone to the Go
tour who wanted to learn Go, and they learned it within a
few weeks, and they're now working somewhere programming
Go every day.
GUSTAVO NIEMEYER: So this is a tricky question, I find as
well, personally at least.
I find that I never stop learning.
I'm still learning Go as well, even though I've started a
couple of years ago, and I hope I don't stop learning.
People can get up to speed with the basic language and
productive as Keith was saying.
And if you're proficient with language, in just a few
minutes you're going to be doing something.
It's going to take a little bit longer for you to get used
to the conventions and what it takes to get a feeling for
what is Go proper, and it's learning
to program in general.
It's a lifelong task, I think.
ANDREW GERRAND: Thanks, next question?
AUDIENCE: Hi.
I was wondering if you guys could share your experiences
with other parts of the development tooling, like
debuggers, profilers, even ID support.
how easy is to work with and use, and help solve real
problems, that kind of thing?
KEITH RARICK: I can just comment briefly.
When working on Doozer, the Go Profiler was invaluable.
It's one of the things that, I don't have a whole lot to say
about it, but it was nice.
It was pretty easy to use, and told me what I need to know.
ANDREW GERRAND: So the profiler that comes with Go is
a very intuitive pprof which is a C++ profiling tool that
Google built, and it provides graphs of memory allocations,
and also CPU utilization in a core graph kind of cell.
KEITH RARICK: And one of my coworkers also said that he
was very happy with the GDP integration.
He was pleasantly surprised.
And if you know him, that's an understatement.
He was pleasantly surprised that it just worked, and it
and it was really, really well.
Nicely done.
ANDREW GERRAND: Take another question.
AUDIENCE: Another moderator question from Josh.
What books on Go would you recommend?
PATRICK CROSBY: Golang.org.
Sorry, I haven't actually read any other Go books,
but it's a good site.
EVAN SHAW: I haven't read any Go books either, but I will
point out again that I'm writing one.
GUSTAVO NIEMEYER: Sorry.
ANDREW GERRAND: Thanks, Gustavo.
AUDIENCE: Thanks.
First I'd like to congratulate the Go team on making
something simple enough that the most interesting thing you
can do is write useful code, which I think is a pretty
impressive achievement.
So I'm first interested in any advice you might have for
people looking to deploy Go potentially into a high
traffic environment, in terms of for instance, like
segmented stacks.
But boundaries, trying to avoid going over those.
I know that there might be a performance issue associated
with that, or Scheduler being rather young.
Are there any words of wisdom to avoid unforeseen
consequences?
ANDREW GERRAND: Do you mean like to avoid trouble spots,
essentially?
AUDIENCE: Yeah, performance or reliability gotchas,
effectively.
ANDREW GERRAND: Maybe you can speak to it, but I was just
going to say the general approach that I've seen inside
Google is just write the simplest code that is
obviously correct, and then if things start going pear shaped
profile, and that recipe tends to work pretty well.
KEITH RARICK: That's exactly what I was going to say.
I mean, that's just you do in general with programming.
Don't worry too much about performance at first, just
write it correctly.
And then if you have performance problems, fix
them, but only the places that you actually need to.
Just profile.
GUSTAVO NIEMEYER: It's good as well to have a good idea of
what operations take the basic timing of operations, right?
Because after you learn that, then you don't worry as much
because you know what are the obvious things that will take
a long time.
AUDIENCE: All right.
Everything works as expected.
Cool.
Thanks.
AUDIENCE: Having used and worked with Go for a while,
how do you feel about using it in, like, offline desktop type
applications?
KEITH RARICK: So this is one of the most fun recent
projects that I've worked on at Heroku.
So we have a command line tool called Heroku that has existed
since the beginning of Heroku, that we use, that all of our
users use to interact with the system, to create new apps and
to change their environment variables, and do all that
sort of stuff.
It's one of those projects that it's been around for a
long time, and it's quite a bit of code, and for a long
time, and so now it's well maintained.
It has a great maintainer who's done a lot of good work,
but for a long time it sort of floated around without a clear
owner, and it sort of a accumulated a whole lot of
code, and it got really slow and bloated, and
it wasn't very fun.
And so one of the things that another coworker did to sort
of jumpstart, or at least compete a little bit and
motivate work on the official command line tool is to make
an alternative in Go just for speed.
So there's a tool out there, you can find it on my GitHub,
and it's called HK, and it's very simple.
It's very similar to the existing Heroku tool, except
it's written in Go.
And there are a couple of other nice things, too, like
the fact that it's a single binary means that the
installation instructions are simple.
You just curl this file down and stick it in the directory,
and you've got it installed.
There's no downloading all these packages and
dependencies and stuff like that.
And in fact, because it's just a single binary, it took
literally an evening for me to write a self update feature,
including a nice binary diff so that the updates are a
tenth of the size that they would otherwise be.
And so it can periodically check to see if there's an
update, and download the update, and apply the patch,
and ask you if you'd like to, yes, do you want this update?
And then it just renamed the file over top, and it's great.
ANDREW GERRAND: I think the process you were describing is
trolling driven development.
KEITH RARICK: Yes, that's what he called it.
Trolling driven development.
ANDREW GERRAND: Rewrite the bad stuff in Go.
Do any of you have any thoughts on, like, GUI stuff,
because I said desktop applications.
I guess none of you are really working on them.
EVAN SHAW: I think where Go is really strong right now is in
the server back-end area.
I would really like to see desktop graphical applications
written to Go.
But I think the library bindings are still young and
there's at least one effort to write a graphical toolkit in
Go itself, which is really interesting.
But that's young as well.
And yeah, I recently saw somebody was [INAUDIBLE].
ANDREW GERRAND: There's actually been
more than one game.
There's a few over the years.
GUSTAVO NIEMEYER: I think I agree with what you
just said as well.
I'm pretty excited about being able to use a graphical
toolkit in Go.
I don't think the toolkits are quite there yet, but the
concepts that Go allows us to use, they do make sense in a
graphical application as well.
So the concurrency aspects, the way that you can handle
information asynchronously while waiting for data and
channels and so on.
this It's usable in graphical applications as well.
ANDREW GERRAND: Great, are there any other questions?
All right, well thanks everybody for coming along.
And thank you very much to our guests.
If we could give them a warm round of applause.