
Get Your Development Team Started With Go - cnbuff410
https://www.digitalocean.com/company/blog/get-your-development-team-started-with-go/
======
luka-birsa
Go Lang was a huge win for us in our server infrastructure. All high
performant but hard to maintain C stuff got migrated to Go in 6 months and we
never looked back. Code is much more managable, less debugging for memory
management, much more readable and shorter by 60%. All that at negligable
performance penalties.

For us its a freaking story of awesome success. Go = ROCKS!

~~~
pjmlp
Possible in all languages that offer native code compilers and are more
developer friendly than C.

~~~
general_failure
Not sure why you are getting downvoted. Without any more context by
grandparent, the parent makes total sense.

~~~
curiousAl
I wasn't aware you COULD be downvoted on HN? Is it just my Tampermonkey script
hiding the downvote button or something?

~~~
skrebbel
I believe that these days you need some secret threshold of karma (HN internet
points) to be able to downvote. Now that you mention it, I have indeed seen
way fewer power displays of the infamous "downvote mafia" recently, so I guess
it works.

------
knodi
People have been poopoo-ing Go lately on HN but let me tell you after using it
in production for over a year. It really makes developers life easier. Why?

1) Error handling, Give you ability to impose defensive practices making
network or another other I/O failures or unexpected responses from external or
internal calls easy to handle.

2) A lot of errors can be caught at compile time. Which means less errors in
runtime.

3) It so simple that all of the build in functions and syntax can be expressed
in less than 16 lines. Makes reading your code and anyone else code very very
easy. Also FMT is sick.

4) Dead simple concurrency.

But all this has still not helped me push Go as the goto lang at the company I
work for, why? Sometimes you work with people that just don't want any change.

Give Go a try you'll be shocked how well its designed.

~~~
Touche
Go is often judged (and praised) based on it's concurrency. But I use
map/filter/reduce, etc. _far_ more often than I use concurrency. So no matter
how great the concurrency story is, having to use for loops all over my code
makes my life much worse.

~~~
NateDad
Loops make your life worse, really? Loops are trivial code that are nearly
impossible to screw up. Writing a loop and writing map/filter probably take
nearly the same time. If this is the biggest problem you have in coding,
you're luckier than most.

~~~
Touche
Loops are very easy to screw up loops because it throws mutation into the mix.

~~~
kyrra
How do you mean exactly? Go has an iterable for map, slices, arrays, strings,
channels with the "range"[0] keyword. The values returned by range are copies
of whatever is in the structure so they should be immune to mutation (unless
you're messing with pointers).

[0]
[http://golang.org/ref/spec#RangeClause](http://golang.org/ref/spec#RangeClause)

~~~
rakoo
He means that what you actually want to do is modify some state _outside_ of
the loop when you're iterating, which means that your loop doesn't provide a
"safe" context where you know what to expect.

Are you sure you're modifying the correct outside variable ? Are you sure you
_really_ are modifying it:

    
    
        bar[i] = f(foo[i])
    

and not creating a new one:

    
    
        bar[i] := f(foo[i])
    

? Are you sure you're not also modifying another variable that you didn't know
was "linked" somehow ?

Given the direction Go has taken, it would make very little sense to introduce
functional programming bits. But you must admit that the immutability/lack of
side effects of the FP gives you a lot of assurance on what to expect.

~~~
kyrra
I think you need to provide an example of what you're trying to say, as the
syntax you showed above is not valid. the := operator is for defining a new
variable, not for creating a new instance of some type. The := operator is
just shorthand.

    
    
       foo := 5
    

is shorthand for:

    
    
       var foo int
       foo = 5
    

the "range" keyword over an array gives you the index and the value at that
index. If you don't need the index or the value, you can put a "_" in it's
place (to save on the allocation).

[http://play.golang.org/p/Z2ejUlN5An](http://play.golang.org/p/Z2ejUlN5An)

You'll notice that foo[i] is still printing "0", because range always creates
a copy of the object assigned into v. Unless you start using pointers, you'll
never have mutation issues.

------
eliben
Good article!

HN's reaction to Go reminds me of Stroustrup quote about C++:

..."There are only two kinds of languages: the ones people complain about and
the ones nobody uses"

So much complaining about how Go lacks this and that features of shiny new
(and sometimes unfinished) language X. In the meantime, as time goes by it
seems that more and more real companies use Go code in real production and are
quite happy with it, despite all the shortcomings frequently listed here.

~~~
wyager
There are also languages that are frequently used, infrequently complained
about, and reasonably well designed (like C). I think Stroustrup has an
emotional interest in thinking otherwise.

~~~
tptacek
I'm not sure it's reasonable to say that C is infrequently complained about. I
think it's more likely that we've just internalized the complaints about C,
and that they now go without saying. (C is my favorite language, for whatever
it's worth).

~~~
sillysaurus3
Why's C your favorite language? It's mine too; it'd just be interesting to
hear your thoughts on it.

------
dominotw
I setup my vim according to plugins described here[1] and go development has
been a breeze ever since.

1\. [http://0value.com/my-Go-centric-Vim-setup](http://0value.com/my-Go-
centric-Vim-setup)

~~~
jzelinskie
You can basically throw a bunch of that complexity away. This plugin[0] is and
one-stop-shop for Go development in vim.

[0] [https://github.com/fatih/vim-go](https://github.com/fatih/vim-go)

------
jzelinskie
I think the bit on managing dependencies could be improved with a bit more
information about what other people have done. For example, SoundCloud
maintains one monolithic $GOPATH in a single git repository that they can then
selectively update. My personal preference to any flavor of the month Go
dependency managers is gopkg.in[0], because it doesn't fool with the official
tool chain (i.e. "go get", "go build"), but still allows for the versioning of
packages.

[0] [http://labix.org/gopkg.in](http://labix.org/gopkg.in)

~~~
sagichmal

        > For example, SoundCloud maintains one monolithic $GOPATH 
        > in a single git repository that they can then 
        > selectively update. 
    

No, we tell developers to use a single $GOPATH on their machine, and check
out/edit code directly in the canonical location, e.g.
$GOPATH/src/github.com/soundcloud/foosvc

~~~
emeraldd
How do you handle a single developer working on multiple
features/branches/issues at the same time?

~~~
NateDad
This is what source control is for. You switch to the branch and hack on it.
In the rare case you need different versions of dependencies, you use a tool
like godep (but if you have to resort to that, you're doing something wrong,
your dependencies should have stable APIs).

Don't use multiple spots on your hard drive for code in source control. Use
source control for what it's made for.

------
sytelus
The problem with Go is that it wasn't designed to implement any large projects
like C was. So the designers would typically make trade offs on perceived
beauty and elegance rather than utility and potential pain in the real world.
Another side effect of this is optimizing for compiler simplicity rather than
optimizing for expressiveness of the language. It's easy to forget we build
compilers not for compiler's sake but for its target user. Here's the quote
from Go's history:

 _we started off with the idea that all three of us had to be talked into
every feature in the language, so there was no extraneous garbage put into the
language for any reason._

I would also argue C++ started in similar fashion but it went exact opposite
route. The balance between minimalism and feature creep can only be achieved
if you are designing language as a side effect of building your own large
scale project combined with a sense of urgency.

Go is currently a lucky language. There is a huge vacuum that Java has left
after Oracle acquisition plus its prolonged stagnation. People who need
compiled languages for their relatively new code base, Go would end up
becoming their choice regardless of its shortcomings. People will enjoy its
minimalism until code base grows to be monster and features starts becoming
sorely missed. This is nothing unusual in world of programming languages. We
have seen COBOL become a gold standard at one point and PHP is still pretty
hot.

~~~
NateDad
"The problem with Go is that it wasn't designed to implement any large
projects"

What? Uh no. That's _exactly_ what it was designed for. Big projects at
Google. It has been stated by the creators of Go multiple times.

The simplicity of Go helps in many ways that are not immediately obvious. You
always know how memory is laid out in a struct, so you know how much memory
you're copying with every instruction. You always know when you're generating
garbage, so you can take steps to avoid it when it matters. In general,
everything your code tells the computer to do in Go is very obvious, so you
can actually reason about what your code does on the small scale and not just
on the big scale. And yet, it does this without the added unsafety of C, and
without all the enormous complexity of C++. And it does that in a way that you
just can't achieve with Java's "everything is an object".

That's why people are flocking to Go. Because it has Java's ease of writing
with C's ease of tweaking, and yet fixes a lot of the inherent problems in
both languages.

~~~
sytelus
You should get your facts right:

As per Wikipedia -

 _Ken Thompson states that, initially, Go was purely an experimental project.
Referring to himself along with the other original authors of Go, he
states:[11] When the three of us [Thompson, Rob Pike, and Robert Griesemer]
got started, it was pure research._

~~~
NateDad
I have my facts straight, thankyouverymuch. Here's an article from golang.org
itself:

[http://talks.golang.org/2012/splash.article](http://talks.golang.org/2012/splash.article)

"The language was designed by and for people who write—and read and debug and
maintain—large software systems."

I'm sure it _started_ as research. Many things do.

------
mooreds
Pretty good article on some of the challenges of getting started with Go.
Certainly the package management issues point to Go's youth.

I would have loved a more detailed explanation of why they chose Go for a
particular problem space rather than C/C++/etc. What problems is Go
particularly good for, and for which problems is it a poor choice?

------
tkubacki
I considered both Go and Dart for my new web projects - but as a former C# dev
I'm too lazy to live without IDE (debugger intellisense etc) and ended up with
Dart. Would love to see more tooling for Go to make it appealing for
'VisualStudio like devs'

~~~
voidlogic
Checkout LiteIDE:
[https://github.com/visualfc/liteide](https://github.com/visualfc/liteide)

Binary downloads
[http://sourceforge.net/projects/liteide/files](http://sourceforge.net/projects/liteide/files)

------
melling
I'm using DO to hack together some web pages to help me verify data for my
mobile app. I'm thinking about building out the pages. However, at the moment
I'm using a simple shell script to start.

#!/bin/sh

export PORT=8080 go run go/spanishdb.go go/Html.go

Any good blogs on using Go in a production ready server? Should I run behind
Apache?

~~~
hedgehog
Your best bet is probably to put it behind nginx and use something like
supervisord to launch the server itself and restart it if it panics
(supervisor will also handle log rotation etc).

~~~
MoOmer
Here here for supervisord watching Go behind nginx. I have this set up in
production; even using the nginx tcpproxy plugin to reverse proxy some RPC
servers.

------
cridenour
I recently documented [1] my efforts to get a great experience with VIM and
Go. It uses vim-go of course, but also supports tags and neocomplete.

[1]
[https://gist.github.com/cridenour/74e7635275331d5afa6b](https://gist.github.com/cridenour/74e7635275331d5afa6b)

