
Why I Program in Go - bcl
http://tech.t9i.in/2013/01/why-program-in-go/
======
pron
For the life of me I can't understand why anyone would give up the power (in
terms of profiling, monitoring and ecosystem, and somewhat better performance,
too) of the JVM, for a language marginally more convenient than Java, and
arguably less expressive than other JVM languages. The only thing I could
think of is a smaller RAM footprint, if you care about that sort of thing.

Whenever Go is compared to Java, the arguments in its favor seem kind of
fuzzy. After all, one of the motivations behind Go was a C-like language with
far better compilation time than C++. And Java already fits the bill. So,
yeah, Go is leaner and more modern -- but certainly not by an order of
magnitude, like other JVM languages. Here, too, the author says that he didn't
like Java's IDEs (really? does Go have better tooling? Because Java IDEs
really get the job done), frameworks etc. But those things are simply the
result of years of changing fashions. Newer Java "frameworks" are just as
lean-and-mean as Go.

There are so many new and exciting languages around, but Go seems to carry the
least "oomph" of the lot. It's basically Java. A little nicer; a little
slower; a lot less powerful.

~~~
zaphar
My day job involves working with Java and C++ on 10+ year old systems. All of
my hobby or side projects are in Go these days with occasional diversions into
haskell, ML or various Lisps.

So I'll try to impart some understanding of why I would switch to Go from Java
or C++.

First lets get some things out of the way. Go is fast enough and getting
faster very quickly and it definitely has a smaller memory footprint. So when
compared to java and C++ in those dimensions it holds up just fine but that
might not be enough to sway someone over to the Go camp.

It's about what else Go has:

* Go is a batteries included language. The stdlib has almost everything you need to get started much like python does.

* Go is fast for development. I mean really fast. I mean like using Lisp in a REPL fast (almost). I really can't express how fast it's development speed is adequately just trust me its really really fast. This is not just about how fast it compiles although that's part of it. (I've literally been able to write, compile, and run a go "script" faster than an equivalent python script.)

* Go makes concurrency easy to get right. I haven't seen any other language get this so right since Erlang.

* Go is concise. There is no wasted typing. It's easy to read and it's easy to write. Every feature of the language is orthoganal. And it tells you quickly when you've done it wrong.

* Go does OO right. Code reuse through composition not inheritance. Polymorphism through interfaces not inheritance. I never have to worry about it with Go. C++ or java? yeah I've got some inheritance related war stories there.

All of these things exist in other languages but Go is the only language where
they all exist together. This is reason enough to switch to Go but there's
more.

Go's future is bright. I don't say this because it has celebrity tech people
behind it. I say this because the foundation they are laying demonstrates the
core team knows what they are doing. Here's some examples.

* Go comes with all the tools you need to programmatically understand Go code. Parser, Type checking, Static analysis is all available via the stdlib. As a result GoCode which adds IDE functionality to the EDITOR of your choice came on the scene very quickly. Java doesn't have this. C++ doesn't have this. Go made it possible to create an IDE as a service with minimal effort. Besides Gocode you also have gofmt. Never worry about code formatting again. gofmt will reformat it for you and it will _never_ break your code. It's 100% safe. I am aware of no other language excepting lisp with this functionality.

Lastly I want to address your "a lot less powerful" comment. I think it's
false. In now way is Go less powerful than Java. It's fast enough to be in the
same league as java. It has a lower memory footprint than java. It compiles
faster than java. And the language itself is if anything more powerful and
expressive than java. It has closures, It has interfaces that are just as
typesafe and yet easier to use than java.

In fact I'll sum it up in one word: Go is _relaxing_.

~~~
estavaro
You need to be commended for defending Go.

I don't think the Go developers hide the fact that they mean go as a Systems
level programming language. It has higher level features, but the developers
don't really mind the fact that Go isn't going to be delivering a whole lot of
high level features. Maybe if they come in the form of libraries...

Funny thing about Go is that as a compiled language, folks often need to send
the source-code to the deployment servers to compile on them too. I seem to
recall that deployment servers shouldn't need to have development tools which
were themselves exposing the servers to bad intention by bad folks. It's just
hard to keep the separation I guess.

Go error handling is not to be taken lightly just because you can ignore error
codes or just print the error and be done with it. I seem to recall that the
core developers of Go demanding that Go users try harder to handle errors.
Something the compiler doesn't really "enforce".

I prefer Dart to Go because Dart starts from a higher level of abstraction
already. Also Dart has been the result of two years of development even if
many of the Dart developers also had plenty of experience with developing past
languages and tools.

OOP already gives us a lot of bondage and discipline. No need for more
incentive by the compiler. Sometimes a couple of extra tools can help our
hands without it being forced by the compiler with every run. Say a tool that
helps to tell us which methods or variables aren't being used. Go forces us to
deal with that on every compiler run. (Even if it can be disabled, but the Go
developers prefer to avoid proliferation of config options.)

It's good to have Go and Dart around. So it's not just legacy (Java) and
Microsoft (C#) dictating the standards.

~~~
tptacek
_Funny thing about Go is that as a compiled language, folks often need to send
the source-code to the deployment servers to compile on them too. I seem to
recall that deployment servers shouldn't need to have development tools which
were themselves exposing the servers to bad intention by bad folks. It's just
hard to keep the separation I guess._

This is what systems administrators with grey beards thought in the 1990s. A
moment's thought about what an attacker who can run a compiler can do instead
of running a compiler should be enough to inform you about how silly the idea
is in practice.

~~~
meaty
Well back in the 90s we kept the machines lean more because disk space was
fucking expensive.

~~~
wglb
Did they have /bin/sh or /bin/bash or /bin/csh?

~~~
meaty
Yes but they were only available to one user and that could only log in via
the console server.

Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the
size of a full 42u rack).

I miss those days.

------
georgemcbay
Those are many of the same reasons I program in Go.

To add another:

* Go's build tools and the language's overall approach to building projects are fantastic.

For the vast majority of projects you don't need an external build manager
like make. One of my least favorite bits of programming in C and C++, even
when I was doing that on a daily basis years ago, was the huge morass of
make/autoconf hell that would grow up around projects and would be very
difficult to understand and reason about unless you were there for the entire
project's development.

With Go open source projects (on git, svn, mercurial) much of the time you can
just

    
    
      go get http://hosted-code-site/blah/(package)
      cd (package)
      go build
    

... out pops a working executable.

~~~
enneff
Actually, the "get" command implies "build" and "install", so it's just (a
real example):

    
    
      go get github.com/nf/todo
    

and you get a todo binary in your workspace's bin directory.

~~~
georgemcbay
TIL.

Thanks, that's good to know. Another (related) wonderful thing about Go is how
fast everything compiles, so fast that it never occurred to me that go get was
building as part of the install.

------
steveklabnik
I just can't get that hyped about Go, but I will tell you (as a Rubyist,
primarily) I've really been enjoying Rust. While they're not directly
competing, my experience is similar to the author's PHP -> Go, which is why I
comment. I have programmed significant projects in statically typed languages
in the past, but this new batch of languages (Rust/Go/Scala/etc) are certainly
neat.

------
introspectif
As an ex-Ruby cum Node.js lover recently converted to Go...

Programming in Go, once it clicks, really does feel relaxing and productive.
If you're a decent Node.js programmer, it's like stepping up to "Node Pro", in
the sense that you work close to the metal with your web server so everything
feels clean and easy to wrap your mind around.

But Go code is cleaner and tighter. The code formatting conventions contribute
to that greatly, as well as the fact that you just don't have to pull in as
much 3rd party code because so much functionality is already beautifully
integrated.

There are a lot of positives about Go that reveal themselves over the first
couple days of coding in it.

I do wish the documentation convention included not only a brief description
each function, etc., but also a brief example.

By the way, I also evaluated Scala for a few days before settling on Go as my
preference. I like Scala, but it quickly becomes a sprawling language as your
explore it further, and frameworks like Play and Lift bring even more baggage
along for the ride. The core language, on its own, was attractive, but
overall, the experience just didn't have the compact, robust, completely under
control, and nimble feeling that came with Go.

Oh ya, and the Go syntax felt ugly and awkward at first. That feeling quickly
faded after a day of use, but it's worth mentioning because I bet it turns
some people away from Go before they even get to the great parts.

Just my 3 cents worth.

~~~
agentS
> I do wish the documentation convention included not only a brief description
> each function, etc., but also a brief example.

It is getting there. If you run godoc locally with tip, you will find many
more examples than there were previously.

See <http://golang.org/pkg/path/> for a current example. And the source for
those examples can be found here:
<http://golang.org/src/pkg/path/example_test.go>. Note that this technique
will work for your own packages as well.

The technology is there, the implementation is still incomplete; but more
progress has been made than is easily visible.

~~~
asdf3
The golang website supports other versions; to see the docs for tip go to
<http://tip.golang.org/>

------
voidlogic
I love Go for many of the same reasons as the author. Go's fantastic
performance doesn’t' hurt either. :)

These micro-benchmarks match what I have seen in the real world:

[http://benchmarksgame.alioth.debian.org/u64q/which-
programs-...](http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-
best.php?calc=chart&go=on&ghc=on&sbcl=on&java=on&scala=on&csharp=on&fsharp=on&php=on&hipe=on&python3=on&erlang=on&clojure=on&yarv=on&perl=on&jruby=on&xfullcpu=1&xmem=1&xloc=1&nbody=1&fannkuchredux=1&meteor=1&fasta=1&fastaredux=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=1&threadring=1&binarytreesredux=1&binarytrees=1)

~~~
pron
They sure do. Slower than Scala _and_ requiring more code _and_ lacking the
awesome power of the JVM. Great choice, indeed.

~~~
voidlogic
Yeah- that is great as long as you don't care about using 30x times more
memory.... The awesome bloat _cough_ I mean power of the JVM in action.

Go vs Scala:
[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=scala)

It will be interesting to re-visit this when Go 1.1 is out as well. Go being
even younger than Scala has a lot of low hanging optimization fruit. :)

P.S. If Go didn't exist I would still be using Java/C#/C/C++ for everything.
(I still use Haskell/Prolog where needed)

~~~
crypto5
> Yeah- that is great as long as you don't care about using 30x times more
> memory.... > Go vs Scala:
> [http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t..).

There is no such thing on that page. You see 30x times win for go only where
program uses very small amount of memory. When memory consumption is
big(regex-dna and binary trees), memory footprint is very similar for both
scala and go(+-10%).

~~~
lazyjones
Makes me wonder why people don't use Free Pascal more ... It shares many of
Go's advantages described here (simple language, powerful libraries) and is
frequently faster and uses less memory (8KB memory in 4 cases where Go uses
700-1200KB!) on the Benchmark Game programs. It's probably the C-like syntax
that tips the scales every time ...

~~~
igouy
Nothing complicated -- Pascal has been out-of-fashion for many decades.

------
danso
I want to try out Go...but I have to make one initial observation...It can be
somewhat hard to Google (ironically) for Go programming examples. I'm sure
there's some tinkering you can do in your search query to get slightly better
results, but "Go" is a difficult proper pronoun to facet a search around.

<https://www.google.com/search?q=go+facial+recognition>

<https://www.google.com/search?q=python+facial+recognition>

~~~
PuerkitoBio
search for golang, most relevant resources will be found with this term.

Edit: also, for package discovery, godoc.org. But golang+anything usually
works.

~~~
danso
I was wrong to doubt Google's foresight.

------
ericbb
> Now, you might want to ... acquaint yourself with [dataflow variables and
> declarative concurrency] because [they are] the centre-piece of Go's
> language features.

Not so. Go has native support for neither dataflow variables nor declarative
concurrency. Go does have native support for message-passing concurrency--but
that's different.

~~~
code_martial
You're right about that. However, I find it easier to understand Go's
concurrency model by starting with dataflow and then adding one more requisite
(channels), than starting with classic fork-and-join and then making a bigger
jump to message passing concurrency.

------
mark_l_watson
"Earlier I mentioned about the JVM being a bad trade-off for phantom
portability. In practice, non-trivial Java programs also require porting for
different systems."

I have used Java since the beginning (and I have written several Java books).
I have had very few portability problems. The JVM is a great ecosystem that
supports several fine programming languages.

------
TallboyOne
If anyone is interested in learning go, my site has a compiled list of
tutorials and so on

[http://pineapple.io/resources/tagged/go-
language?type=tutori...](http://pineapple.io/resources/tagged/go-
language?type=tutorials)

~~~
theyak
I have been unable to find a good web server tutorial. Everything seems to be
listen, process page, done, repeat. This doesn't seem to allow multiple
connections at once, especially if the process page process takes a long time.

~~~
enneff
Go's net/http package is concurrent behind the scenes; each request is handled
in a separate goroutine. You just write your HTTP handlers in the obvious way
and the concurrency is taken care of by the runtime.

<http://golang.org/doc/articles/wiki/>

------
crusso
_Java is perhaps the most depressing language I've ever programmed in._

I'd have to agree with him there.

------
jhuni
> _Scalars (integers, characters, strings, floats, booleans), sequences
> (lists/arrays) and maps (key-value pairs) as built-ins are enough to support
> almost all data models._

There is some wisdom in Larry Wall's decision to make scalars, lists, and maps
the main data structures in the Perl programming language and to give them the
sigils $, @, %. The considerable wealth of Perl libraries available on CPAN
today demonstrates that you can support essentially all data models using
these three data types.

------
c141charlie
Go nails code readability and documentation better than any other language I'm
aware of.

For example, look at the package documentation for Go's list data structure at
<http://golang.org/pkg/container/list/>.

5 seconds of reading this you immediately get what the package does and how to
use it. Now let's say you want to know how the list is implemented. No
problemo. Click the package files link list.go,
<http://golang.org/src/pkg/container/list/list.go>, and you're presented with
very readable source code.

Now compare this with Java. I just Google'd Java List. First link is this:
<http://docs.oracle.com/javase/6/docs/api/java/util/List.html>

Documentation looks OK, but wait, this is the interface. I want to see docs
for a concrete implementation. I'm tempted to click on the AbstractList link,
but oh wait, that's just another non-concrete class that other List classes
probably inherit from. Let's see, let's go to the ArrayList ... this looks
good.
[http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList...](http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html)

Nice. I wonder how they implemented this. And I'll keep wondering because I
can't find a link to the source code. Maybe there is a link to it, maybe not.
We're talking about Oracle so without knowing better, I'll assume there is not
...

Let's try Scala. Google "Scala List". Click on first link. [http://www.scala-
lang.org/api/current/index.html#scala.colle...](http://www.scala-
lang.org/api/current/index.html#scala.collection.immutable.List)

What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with
LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with
LinearSeqOptimized[A, List[A]]"

Oh sweet, this thing has all kinds of methods, i.e. ++, ++:, +:, /:, :+, ::,
:::, :\

Reading further, I see section in the documentation called "Shadowed Implict
Value Members". Wow, I have no idea what that is.

Looking back to the Go documentation, I immediately "relax" as another
commenter put it.

For some reason, I think Scala will end up being the next Java. It has so much
momentum, runs on the JVM, has seamless interop with Java code. Has the Play
Framework, AKKA, and thousands of other awesome libraries written for it. And
if Scala powers Twitter, then I think this answers the scalability and
concurrency question.

While I'm bullish on Scala, at the end of the day, I find Go's simplicity make
it more beautiful than any other language.

~~~
rorrr
> _Go nails code [cut] documentation better than any other language I'm aware
> of._

That's because you haven't seen PHP's documentation.

Look at your Go's list example.

It doesn't even show how to create a list and fill it with items.

It doesn't have users' comments.

It doesn't explain much about the data structure. Can it be a circular doubly
link list, for instance?

Is there a method to empty the list, or quickly insert more than one element?

Instead it has strangely named sections (like "type Element") that aren't
obvious to somebody new to the language.

Sorry, but this documentation is shit.

~~~
enneff
That's a bit harsh. Library docs are for users of the language. I grant that
the list package could use more docs (I personally find it a bad example) but
for someone who knows Go, all the important stuff is there.

Juba surprised that you rate the PHP docs so highly, particularly the user
comments. Typically those comments contain terrible advice!

~~~
rorrr
Users' comments are important to figure out unusual behaviors, bugs, edge
cases, to clarify documentation in general, and to add code examples. Of
course, some of them will be incorrect and bad advice, that's why I think PHP
docs should add up/down voting on each post.

More than anything, it creates the sense of community. You always know there
are people reading and writing stuff about a specific method, and, most of the
time, it's helpful.

Considering how bad and inconsistent PHP is, their documentation is amazing.

------
guilloche
I am C and lisp fan and think OOP as non-sense. I used python a bit but hate
its performance. Can I still get something from Go that can not be provided by
C and lisp? Does go provide great flexibility by C and lisp? BTW, I think
emacs is the best IDE so I do not care any tools/IDEs at all.

~~~
djhworld
Go is a bit like C but it has GC so it depends on how much you value the fine
degree of control of memory allocation that you get with C.

Personally I think Go has a lot cleaner syntax than C and the tools give a lot
more "friendly" error messages when compiling your applications.

You do still get nullpointerexception runtime errors though but that's an
inherent problem with the nil/null type.

~~~
guilloche
Thanks for replying. It seems GO is not for me at least now. What I want is an
optional strong typed script language with highest performance. Lisp serves me
well here.

I have only three real things to care about a language:

1\. Performance and thus optional strong typed is required. Go can have
optional strong typed system, so performance may be improved in future, but
its GC seems a big warning for me. I want to have option to allocate/free
memory myself. the GC is also an enforcement of some design principle, which
is also a big minus regarding the next point.

2\. Great flexibility, basically the language should not make any decisions
for developers. I dislike C++ for its OOP approach to make way too many
decisions for developer. I want no limitation from a language. I can self
restrain to avoid all troubles from freedom, I can design OOP/GC myself if it
is neccessary, but please not make decision for me. (C++ did not enforce OOP,
but most of the extra part beyond C usually distorts a good design otherwise)
Lisp and C are almost perfect here. Does GO allow any weird design people may
think of? any enforcement of some supposed-to-be good principle?

3\. A script, which can relieve me on all details. Occasionally, I may not
care performance, and I want life easy. Python is prety good here. Lisp is
good but lack of compiling on ARM machines is a big disadvantage.

~~~
djhworld
You might get a bit of mileage out of 3., you can write go applications quite
quickly and the optional typing makes it feel script-ish.

Also Go does compile on ARM.

------
tsahyt
Thus far I feel that, if any language was ever going to replace C, it's
probably Go. In a way I sympathize with Go. I like it for the compactness and
simplicity. Those are two design decision which seem to be unique among modern
languages and exactly the two things I like most about C.

------
mcartyem
Can anyone explain in less than ten words the most important reason to program
in Go?

~~~
Symmetry
"Many of the best part of both C and Python"?

------
p0nce
I prefer to use Hypescript for all my kickass cloud deployments.

------
martinced
His second point is, to me, the most important for would-be language
designers:

 _Standardized formatting: A standard tool to enforce formatting rules that is
not subject to change based on the team members' or leader's opinions is a
welcome feature for lowering the "not my code" mental barrier._

This is a godsend. The best thing to have happened to our industry since a
very long time.

But his first point is oversimplified:

 _The compiler not only checks for code that can theoretically result in a
runnable program..._

It's not exactly as if Go did solve the halting problem or we'd _ALL_ be using
Go. So I think a bit more in-depth explanation would have been welcome.

~~~
kicktheshoe
If the biggest gain for the language is a formatting utility then that
language is not worth learning.

~~~
jlgreco
What is the "biggest" gain a language can have is a matter of taste. Someone
who considers the handling of formatting and style to be the "biggest" is
likely to be one who values those things highly.

That you do not value those things as highly is not particularly profound. It
doesn't mean that he is wrong to be excited about that, nor that he is excited
about the wrong language, nor even that there is no reason for _you_ to be
excited about that language. It only means that there is no reason for you to
be excited about that language for that particular reason.

~~~
j-kidd
> Someone who considers the handling of formatting and style to be the
> "biggest" is likely to be one who values those things highly.

Not really. Someone who values those things highly would have written the code
as such, instead of relying on a utility to reformat the code.

~~~
burntsushi
Are you being purposefully obtuse? Do we really all just use and read our own
code and not the code of others?

Having `gofmt` drastically increases the probability that any particular Go
program has the same style/formatting that you're used to.

------
af3
It feels like Go is the new Fortran.

------
nnoitra
We don't care you why program in Go.

~~~
codygman
I care

