
"100% of our production system is now running Go" - enneff
https://groups.google.com/d/topic/golang-nuts/hC0aJ8IASi4/discussion
======
aaronblohowiak
Creator of SASS and Haml now using Go for whole production system.

When asked about surprising things about Go, its creators have said that they
expected to recruit people from c++ communities, instead it seems to be more
ruby/python people.

~~~
jonathansizz
I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go
is more of a Java replacement.

And it's interesting to see Python and Ruby being squeezed lately, from
various directions; Clojure, Go, other languages. Since Python went mainstream
and started being picked up for serious projects, it naturally came under the
spotlight a lot more than it had previously, and I think many people have
started to see some of its warts. The transition from version 2 -> 3 wasn't
exactly a smooth one, either. Furthermore, although Python is a pretty good
all-round language, it doesn't really excel at anything in particular, unlike
for example Perl which continues to maintain a strong niche in the areas of
text processing and system administration, despite its popularity having
fallen away in some of the other areas it was formerly strong in.

In my case, although I have recently moved from Perl to Racket for larger
and/or more complex work, I still use Perl a lot for small, simple scripts
(which constitute most of my programming). A couple of the Java guys I know
switched from Python to Clojure for scripting tasks (I could never convince
them to like Perl..), and have started to take an interest in languages like
Scala and now Go for more substantial projects.

For many years now, Python has been the fresh, fun challenger going up against
older (and perhaps clunkier) languages, whereas now things seem to be shifting
and Python may soon find its role has reversed and it has become the old,
crufty language.

~~~
pcwalton
"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go
is more of a Java replacement."

I basically agree with this as a Rust developer (although I'm not sure about
Go being in Java's niche; I think of it more as in node.js's niche -- highly
scalable web apps). Early on, I think both Rust and Go were thought to be
targeting the same segment, but it turned out that we really weren't.
Personally, I'm completely fine with that; different language designs are
appropriate for different roles. The huge amount of work that we've done to
make non-allocating and manually-memory-managed code easy, predictable, and
type-safe is totally overkill for Go's niche, for example, while for games and
web browsers this sort of thing is essential.

~~~
heretohelp
As someone who's tried (and failed) to learn Rust in the past:

I'm going to elide any commentary about the syntax for now, as I know why it
is the way it is (the type system/annotations). I'm basically just going to
expound on one thing for the sake of emphasis.

For the love of god make Rust more _accessible_. I don't mean dumbing down the
type system or abandoning regions (I really hope that works out). I mean the
frickin' _documentation_. Digging through the core libs to figure out how to
dp fairly common case stuff is obscene.

Part of the reason I like to tinker with Go in my spare time is that it's
_extremely_ hygienic, clean, cheap, and cheerful.

Look at the way the "go" binary works, it does everything. It does builds,
automatic formatting of code, the works. And it just "works".

On top of that, I'd consider getting somebody more knowledgeable about Rust
and get them to team up / pair-document with somebody who is a goddamn dumbass
like me and start building tutorials/documentation together.

I can't imagine the language's syntax and features are so nascent that
tutorials and docs for core functionality/libs would be out of the question,
you're already prototyping that web browser engine.

Documentation is a UX problem, like syntax. Syntax _alone_ crippled Erlang,
please don't let obscurity harm a language I am very excited about.

If there's any way I can help (maybe a trail of bread crumbs/notes from me as
I try to learn it?), let me know in this thread or via email.

~~~
pcwalton
Yes, the docs are awful at the moment. It's mostly a question of making sure
things are stable before we commit to writing a lot of docs; we absolutely
need better ones. The standard library tends to use the bleeding-edge features
more than user Rust code (as it contains implementations of core traits and
whatnot), so its churn is high. Despite what others have suggested, I don't
think it needs a total rewrite, but various names should change.

A "go"-like binary is on the roadmap; it's mostly a question of refactoring.
We have a pretty printer, a doc generator, a package manager, and a compiler
(all in various stages of completeness); the trick is to just bundle them into
one nice package.

A trail of notes would definitely be helpful, to see what the initial hurdles
are for beginners.

From what I've seen the biggest problem is that 0.3's syntax is totally
different from the unreleased 0.4 (due to be released next week). Most people,
understandably, build from the packaged 0.3 and none of the examples in the
documentation work. 0.4 contains the syntax we're committing to; most of the
changes from then on should be backwards-compatible with it (unless you use
the deprecated stuff, which we're adding warnings for).

~~~
zedzedzed
(due to be released next week).

I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of
the past alphas? Is it finally becomming a beta?

~~~
pcwalton
My mistake, it's actually 2 weeks ("mid-September" is the target date). Still
close. It's still an alpha, but there are _huge_ changes, and most
importantly, syntax becomes "slushy" after 0.4 (not frozen, but massive
changes have a high bar to clear).

------
zeeg
I'd be really curious to know what their "800 million requests a month" means.
When we actually added up numbers a while back, we were doing around 250
million requests to our Python machines/day, and we only had 200 servers
(which included dbs/etc), that was around 3-3.5 billion pageviews a month
IIRC. We now have 300 machines and do about 5 billion pageviews, but that
completely ignores the huge amounts of requests to our realtime stream servers
and our API (which get shit on every "pageview" at least once).

~~~
jacques_chester
It's really hard to compare different systems without knowing what kind of
complexity each pageview engenders in terms of backend processing.

At one end there's flat HTML files, where you could serve 800 million
pages/month from maybe a single particularly beefy server; at the other fully-
dressed SOAs and CEPs and your uncle's pet dog rover performing multivariate
regressions, meaning you need 9,000 servers.

~~~
zeeg
I'm hoping they'll provide some more insight into what the breakdown of tasks
are between the machines, and if that 800 million number is actually correct.

It seems extremely high for what my absolutely-no-idea-what-these-sites-could-
possible-need-that-many-servers-for thought process can fathom.

------
bad_user
I want to try out Go, but the problems exposed by the garbage collector on
32bit systems scared me away.

Is that still the case with the latest version 1.0.2 ?

Also, is there any chance for a precise generational garbage collector to get
implemented for Go? As far as I know, pointers make the implementation of
precise garbage collectors difficult.

~~~
akavel
AFAIK, yes it is still the case (although somewhat slightly improved), but
precise collector is officially expected (and being worked on) for version 1.1
. The latter was explicitly said on a Q&A session on Google I/O conference,
the video is available somewhere on teh interwebs.

edit: I think it's this one: <http://youtu.be/sln-gJaURzk> ("Meet the Go
team"), but maybe some other from: [http://blog.golang.org/2012/07/go-videos-
from-google-io-2012...](http://blog.golang.org/2012/07/go-videos-from-google-
io-2012.html) (sorry, don't have time to watch them all again now to make sure
;)

~~~
bad_user
That's good to know, thanks.

------
tocomment
How do you run golang as a server? Can anyone point me to a basic tutorial? Is
it still running under something like Apache is golang IS the server somehow?
If so Wouldn't each http request have to fire up the compiled executable?
Isn't that slow?

~~~
eckyptang
The compiled output will contain your network server. you run the process and
it listens on a socket. It is pretty straightforward. Using HTTP as an
example, each request will run in a goroutine which is somewhere between a
thread and a coroutine.

It is extremely fast.

The main risk is process failure which is very rare but can be mitigated via
putting a front end balancer such as nginx or apache mod_proxy. Process
recovery and spawning can be managed by another tool such as supervisord.

However, you can run a process happily from init if you desire.

~~~
tocomment
I was always taught never to write my own web server since something like
Apache has been tested on millions of sites, and you have security experts
designing it.

Does writing your own server in Go kind of violate this idea? Are you opening
yourself up to re-inventing a web server and repeating decades of mistakes
something like Apache has already figured out and fixed?

~~~
eckyptang
You are correct - you should never write your own web server. In this case,
you're not writing your own web server. There is one provided with the
standard library which will be embedded into your binary.

You are writing a bunch of handlers (as you would with Apache) and plugging
them into the compiled in web server from the standard library.

For network servers, there is standard library support for SMTP, HTTP, normal
stream based text protocols etc as well as serialization formatters and
parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.

------
joejohnson
"100% of our production system is now running Go as 95% of our application (C
being the other bits)"

So... 95% of their production system is running Go.

~~~
ww520
I guess it's playing word semantic. 100% of their MACHINES are running GO in
SOME capacity, while other languages play some roles in other capacity.

~~~
enneff
I interpreted it as meaning that 100% of the code in the critical path is Go,
while their greater application also includes some C code.

------
dbecker
This is a really awkward sentence: "100% of our production system is now
running Go as 95% of our application."

I'm curious what the 5% is that they didn't convert to go.

~~~
jmaygarden
Read the whole paragraph. It's C.

"100% of our production system is now running Go as 95% of our application (C
being the other bits). Not side bits, but our critical path."

~~~
dbecker
I meant "what functionality is the remaining 5%." Not "what language is it."

Basically, once you are 95% Go, what parts are hard to convert to Go to make
it 100%

~~~
luriel
Probably binding to pre-existing C libs.

It will take some time to replace 40 years of existing accumulated C
libraries.

~~~
Evbn
That would be silly. It's silly to talk about the source language of third
party libraries when discussing languages you use. 3rd party library code is
all object code or bytecode for all it matters to your project.

------
siculars
It's really annoying to have to log in to read something on google+, or groups
for that matter. I just won't do it.

~~~
spicyj
This happens only if you have some Google login cookies already -- if you
delete all your Google cookies then you won't be asked to log in.

~~~
siculars
Um. What? Did you just tell me to fuck myself?

~~~
spicyj
No, I did not.

~~~
siculars
Along the lines of... <http://howfuckedismydatabase.com/nosql/>. Aka, I
shouldn't need to "delete all my Google cookies" to read a post.

~~~
Achshar
Can you explain what's going on here?

------
pkulak
How's the garbage collector these days for Go? Is it close to the performance
of the Java GC?

~~~
Evbn
It's not as sophisticated, but Go structs are smaller than similar Java
objects, so that helps beat the tradeoff

~~~
danieldk
I like Go, but this is total nonsense. It does help that you can embed values
in a struct, rather than using pointers. But marking everything that looks
like a pointer is not efficient. Not having generations does not help.

Go is still very young, a better GC will come, just give it time. In the
meanwhile, let's not pretend that the current sub-par generator is as
performant as that of modern JVMs.

~~~
luriel
Go code does produce considerably less garbage than Java code.

And with Go if you really care, you can be even more careful and produce close
to no garbage.

Control over memory layout is really useful.

------
bitcartel
@enneff Do you know if they are using the default gc compiler, or gccgo which
is supposed to have better optimisation?

~~~
luriel
I'm fairly sure they use the main gc compilers.

gccgo does better at some things, but the default compilers do quite well
already.

------
ck2
_To continue shopping on m.macys.com, please enable cookies in your settings._

Really? in 2012?

~~~
kyrra
It's a shopping website. It's sorta hard to do cart management without
cookies.

~~~
dkroy
They are a good fallback, I think he is talking about using things such as
Local storage, session storage, or global storage. Since the site is their
mobile site I see no reason why they aren't using the new technology available
to us since most mobile devices would be able to use it. DOM storage seems to
be a better fit for shopping carts than cookies anyways.

~~~
pilif
It's not about the shopping cart. It's about all the session data, especially
for authentication. While you could use Dom storage for storing a session ID,
you would have to send that through to the server with every request which you
get for free with cookies.

Additionally, cookies can be marked as http only or even as secure, making it
very hard to lose the token by virtue of a fire sheep like, or even just XSS
attack.

For that reason, I personally would prefer a site using (session) cookies to
one hacking it via DOM storage any day.

And finally, depending on the store you might want to persist the shopping
cart between visits- likely across machines. Thus, the cart should be stored
on the server and not in DOM storage.

~~~
dkroy
Cookies are stored on the client just like DOM Storage, so nothing is free
when it comes to requests and communicating with the server. I understand that
both still have their place. Though I generally prefer to use DOM Storage for
most things now depending on the use case. I also complete agree about keeping
server-side session data.

~~~
pilif
with "free" I meant without additional effort for the developer.

When you set a cookie with a Set-Cookie header, the client will automatically
send the cookie with all further requests.

When you put the session-ID somewhere in DOM storage, you have to manually
amend all requests with that session-ID - either by appending it as a get
parameter or, when you do nothing but AJAX, as an additional request header -
but whatever you do, it's considerably more effort.

Also, looking at our logs, I see way more users with DOM storage disabled than
with cookies disabled, but that might just be my user base.

~~~
dkroy
Alright, thanks for the clarification on "free", I realized that is what you
might have meant after posting.

That last bit about your logs is surprising, thanks for that bit of info. I
may need to go do the same. Either way I use a storage wrapper so I am
accommodating both types of users.

------
afc
Whoah, 500 servers to handle an average of ~300 queries per second? Even if
you generously assume they have traffic patterns that sometimes go all the way
up to sustained say 5K queries per second... 500 servers? Isn't that like ...
terribly wasteful?

------
zedzedzed
There was this dart. It somewhat failed, so what they did was, screw up a good
systems language so that it sarted looking like dart..

------
jebblue
Edit: I just posted 3 minutes ago and I'm already in gray text. Wow.

We search with Google, run our phones with Google, run Google's browser, now
they want us to write all our code in Google's language. Why Google? What's
wrong with Java? Other than the fact that Oracle owns it, I miss Sun. Scott
McNealy tried to make the technology world better. Scott, Gosling.
Google...why should everything we do all day and night be about Google?

<http://en.wikipedia.org/wiki/Go_(programming_language)>

>> The syntax of Go is broadly similar to that of C

C, seriously? C??!? Why? Why would I want to go back to ... C?

>> Of features found in C++ or Java, Go does not include type inheritance,
generic programming, assertions, method overloading, or pointer arithmetic.

And that is a good thing or a bad thing or what?

>> Go allows a programmer to write functions that can operate on inputs of
arbitrary type, provided that the type implements the functions defined by a
given interface.

Huh? Oh I can pass interface references, ok.

>> A Go interface is best described as a set of methods, each identified by a
name and signature.

That sounds like Microsoft's crappy COM from the 1990's.

The code sample on that page shows there are no braces in the if evaluation
statements. A wise man, Peter Van Der Linden formerly of Sun's Compiler Group
and author of Deep C Secrets wrote about using more braces if needed as
explicitness is always better. I agree with that.

At this point, I think I'd rather program in Groovy or even go to JavaScript
if I had to, than use Go.

Oh...the language name sux.

Tip, buy Oracle and fix Java or by Java rights from them and fix it, then
programming in a language owned by Google when you own so much of our lives
now wouldn't be so bad.

PS How does Guido Van Rossom feel about Go?

~~~
brianobush
>> C, seriously? C??!?

For those, like myself, that like C and do systems programming. Really never
understood why people dislike or fear C so much. It is the foundation for so
many systems and libraries.

~~~
jessemc
The main problem people have with C syntax is that it's 'old' and 'old' things
are bad because new things are better. We're an industry built on fashions.
Largely the outcome of the massive success programmers can have without any
formal education and so just get by knowing the "best" way to do things
instead of understanding why.

~~~
numeromancer
_There are two kinds of fools: the first kind says “it is old, and therefore
it is good”; the second kind says “it is new, and therefore it is better.”_

