
Go at SoundCloud - cypriend
http://backstage.soundcloud.com/2012/07/go-at-soundcloud/
======
anon01
We've just started using Go as well. It smokes our Python app in terms of
speed, and is fun to use (maybe just because it's new?).

I have always wondered, however, that if moving to a new language seems great
because of the language, or because you have such a better understanding of
the implementation of the problem you are trying to solve.

~~~
agentultra
You bring up an interesting point about "new."

New is fun. Exploration is fun. I think a lot of people will swear by a new
language simply because it's not old and probably doesn't suffer many of the
same deficiencies they're used to in their "every day," language.

This to me is an illusion however. One must remain skeptical and treat new,
untested languages with even more scrutiny than an old one. Many of these new
languages will make extraordinary claims. Discovering the evidence to support
these claims is often left as an exercise to the programmer.

That being said, new has a lot of advantages. It's free to try to break away
from past paradigms that perhaps limited programmers. Stability can always
come later once the core ideas have been fleshed out. And it's always fun to
work on fresh ideas rather than refining the same old ones that we're plagued
with.

Personally I wouldn't use a language and compiler that only just reached 1.0
this year in a production system. If I was really interested in Go I'd
certainly hack with it and perhaps on it, but I wouldn't trust it to be
reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over
brilliance when it comes to building systems that are dependable and robust.

~~~
icebraining
Is it really helpful to judge a language by its version number? Go is a very
conservative language, in that it only uses well known and studied language
features, and has been in production at many companies, including Google,
Canonical, CloudFlare, etc.

Certainly it deserves more faith than any random language designed for the
exploration of new paradigms and features and which is only used by its maker?

~~~
anon01
Version numbers are pretty useless these days. I would certainly put a lot
more stock in a 1.0 from the Go team than, say, my company. We use version
numbers more for marketing than anything else.

Personally, I'm not as worried about reliability as I am roadblocks. Say, for
instance, we spend a month moving our framework over to Go. Then we find a
problem that is yet unsolved. Either we solve it ourselves at an unknown cost
or we have to just ... wait.. until another group solves it while we make
payroll in other ways.

I'm lacking any real evidence here, maybe Go doesn't have a library for our
Message Queue (not true, just an example). Now we aren't just porting, we're
writing a pooling message queue interface that is beyond our pay grade in the
language.

~~~
duggan

      > spend a month moving our framework over to Go
    

Seems a little extreme. Just use it for small, discrete projects. No need to
bet the farm.

------
laktek
Shameless plug for my Go articles for anyone who wants to get a start -
<http://laktek.com/tag/go>

(Yes, I will commit to finish the rest of the series)

------
ungerik
Go also works very well at STARTeurope, powering our event-platform
<http://startuplive.in/> Developing a high level webframework from scratch
just for one website was a bit of a crazy undertaking:
<https://github.com/ungerik/go-start> (sorry, the documentation needs a big
update and a tutorial. Most time was spent on running stuff and shipping
features...).

~~~
ungerik
Just don't use Go on 32bit systems, the 32bit garbage collector leaks. On
64bit systems everything is rock solid.

~~~
Symmetry
Garbage collection is actually a lot easier with 64 bit pointers, since the
odds of a random collision between pointers and non-pointer data goes way, way
down. And because the ratio of memory in use to total address space goes down.

------
goostavos
I'm still a bit of a novice, could someone elaborate on what he means by
operator overloading being "problem creating?" I thought that was one of the
main, 'core' concepts of OOP. Inheritance, and polymorphism.

How would you make something like a GUI without being able to specialize
classes by overriding certain methods?

Have I misunderstood his point?

~~~
Lewisham
His point is that, if you aren't familiar with the code, operator overloading
can be difficult to read. It gives objects the appearance of being native
types, and it is sometimes not entirely clear what the result of the overload
might be. What does "dog + cat" equal? In an extreme example, if you are crazy
enough, it might make sense to have animal + animal = baby animal. You need to
temper that example down to something closer to reality :)

I personally like overloading, but I think it's probably too easy to abuse,
and I can see how it would cause problems with a team size larger than 5.

As far as I can see, whenever the Go team encountered a language feature that
could possibly be abused, they always deferred to leaving it out. Whether that
is good or bad I'm not sure we will know until we have years of experience
with it.

~~~
luriel
> As far as I can see, whenever the Go team encountered a language feature
> that could possibly be abused, they always deferred to leaving it out.

All features can be abused.

The Go philosophy is more to leave out features that obscure the meaning and
understanding of code (what is also known as "magic").

Also part of the Go philosophy is to not include any feature unless it is
clear that its benefits are greater than its costs, and which might interact
in unpredictable ways with other existing features.

In other words, the default is to leave things out, rather than to include
them, the opposite of a kitchen sink approach.

------
fjellfras
What sort of development environment are others here using for go (if using it
at all, of course) ? I've had reasonably good experience with the go-mode in
emacs.

~~~
shawnps
I'm using vim with the vim plugins that come in go/misc/vim. I use :Import and
:Drop for adding and removing imports, and :Fmt to run gofmt in vim. I also
have a git pre-commit hook that runs gofmt.

~~~
stock_toaster
Whoah. I had a few vim configs from a while back, but hadn't checked for
anything new. Thanks! :Fmt, :Import/:Drop, and :Godoc are glorious.

------
truebosko
The way they describe Go as a WYSIWYG language makes me think of functional
programming languages (e.g. mostly of elimination of side effects.)

~~~
geoka9
It makes me think of getting rid of OOP and saying goodbye to the
overengineering overhead it involves.

It took us 25 years to begin to see that the king is naked!

UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du
jour - functional programming.

~~~
mseepgood
But Go doesn't get rid of OOP, it just fixes it.

~~~
sausagefeet
Does it? Seems like Go just has somewhat weak structural typing and a poor (by
2012 standards) type system. No parametric polymorphism? Whaaaaaaa

~~~
mseepgood
Parametric polymorphism has nothing to do with OOP.

------
zaiste
Nowadays, polyglot approach is the only right path for a software company.
When I arrived in Berlin a month ago, I was positively surprised that
SoundCloud supports local Clojure or functional programming groups. Keep up
with great work!

~~~
_ak
And, of course, they regularly host the Berlin Go User Group.

------
shortlived

      especially, as most new engineers on Go projects lament, during error handling
    

Does any have pointers to reading material or care to explain the lack of
error handling in Go?

~~~
zemo
it's not there there's no error handling; it's that there's no exceptions.
Instead, you use multiple return values, one of which is an error, and you
check the return value for an error. It forces you to handle errors at the
call site and makes diapers unimplementable.

~~~
chengiz
How does it force you to handle errors? Cant you choose to ignore the return
value?

~~~
osi
You can absolutely ignore it. Or in the case of the Write call, which only
returns an error, just never assign it.

go's error handling is nice, but since it doesn't force it on you, it leads to
errors of omission.

~~~
skybrian
If the function returns a useful value and an error then you'll have to assign
to error to "_" to ignore it, which is a pretty big hint to the reviewer that
it's being suppressed. So in cases where you want to "force" error checking,
returning multiple values is probably good enough.

------
user911302966
I'm confused. I see the word "engineer" appear several times, but the company
appears to offer MP3 recording technology and a "share" button.

Where are the moving parts?

~~~
wetbrain
I've heard the same about Twitter. All they do is publish short messages, why
do they have 1000 employees?

There's always many problems that aren't immediately apparent but difficult.

------
mseepgood
ʕ ◔ϖ◔ʔ <\- Gopher

------
brandoncapecci
Why can't people just be satisfied with Ruby or Python...

~~~
emmett
Because this is how progress happens. You could have equally asked about Ruby,
why can't people be satisfied with Perl and PHP?

Why would this bother you that they are trying new things and learning?

~~~
brandoncapecci
Changing languages is not how progress happens. It's only progressive when the
long-term benefits of the language outweigh the inefficiency of training all
your devs to use it. Assuming that is true for Go (debatable), at the end of
the day, SoundCloud still gimps their hiring pool far more than if they choose
something like Node. Learning doesn't bother me at all - I like learning - but
I can't advocate for battle-testing Go in a mainstream environment when their
are plenty of other fast and tested languages. If Go evolves into a language
that is more desirable in the everyday stack, that process should be organic,
just as it was when people decided to switch to Ruby.

