
Why Go Is An Excellent Modern Programming Language - bsg75
http://engineeredweb.com/blog/2013/why-go-excellent-programming-language/
======
gnuvince
I like Go, but I feel that it only addresses one of the urgent problems in
computer programming, concurrency. Another very important problem IMO is
correctness and I find Go lacking in that area; the onus is squarely on the
shoulder of the programmer. Languages like ML, Haskell, or Rust offer
facilities to make correct code easier to write (or incorrect code harder to
write, depends on your view point).

~~~
PommeDeTerre
Rust appears very promising, but having followed it for some time now, it's
still severely lacking in terms of stability.

I'm talking about the stability of the language feature set and the amount of
change it's undergoing, rather than the quality of the implementation or
anything of that sort.

While it's good to see the language evolving and improving, this type of churn
also means it isn't very practical to use.

For example, some experimental Rust code I wrote a mere 6 to 8 months ago is
now basically unusable with recent versions of Rust due to language
functionality changes, syntax changes, and library changes.

I keep hoping that it'll start to stabilize, even just on a feature set and
standard library that may not be perfect, but will at least be usable for
longer than a few months. Yet this doesn't seem to be happening. This lack of
stability will start to significantly hurt its adoption at some point.

Go has taken a better approach, in my opinion. It isn't perfect, and it's
lacking some important functionality, but at least there's a version that's
usable, well-supported, and usable well into the future, even if the language
does continue to evolve in incompatible ways.

~~~
quacker
I agree. This is going to affect Rust's adoption if they aren't careful.
People are hesitant to write tutorials, documentation, or code that may need
to be rewritten later.

But I still give Rust a pass on this for the time being. Rust is a younger
language than Go (Rust is not yet at version 1, while Go is at 1.1.1), and
Rust supports far more compile-time features.

~~~
PommeDeTerre
When it comes to the Rust tutorials, documentation and code that do already
exist, a lot of the information is now very misleading.

This may even be more harmful than no documentation at all, especially for
people new to the language.

While this is an issue for other languages, I've found it to be far more
severe with Rust.

~~~
pcwalton
Other languages went through a lot of change too. They just did it behind
closed doors. We could have done our development behind closed doors too so
you wouldn't see all the churn, but that's not the way we work at Mozilla.

Furthermore, Rust is quite ambitious. Getting lifetimes and the borrow check
to work right is hard and involved research in all senses of the word; read
the borrow check source code sometime. We did not just change things because
we felt like it.

------
cliveowen
Go is an interesting and promising language and I look at it as the spiritual
successor of the C programming language. That said, I don't find it all that
easy to pick up. At all. Despite having some experience writing in ANSI C
(C89) I find getting started with Go pretty painful, not for the syntax (it's
simpler and more readable/declarative) but for everything else, starting from
the library. It's not straightforward or intuitive how to perform even the
basic tasks (as basic as reading/writing from files/sockets) and even the
online documentation isn't that good: it's just a bunch of prototypes. There
are many new concepts/constructs that you may first think as a useful addition
but that are actually a pretty fundamental part of the language (e.g. slices).

I'm sure that with time and the right mindset one could actually enjoy writing
software in Go.

~~~
thirsteh
Weird. I had the exact opposite experience. Extremely easy to pick up,
especially if you are familiar with both C and Python, since Python lists are
fairly similar to slices.

Also, the documentation is far better than e.g. that for Java and C#:
[http://golang.org/pkg/io/](http://golang.org/pkg/io/) /
[http://golang.org/pkg/io/ioutil](http://golang.org/pkg/io/ioutil)

Reading a file into memory is as simple as:

    
    
        data, err := ioutil.ReadFile("filename")

~~~
ancarda
I can side with OP, I find the documentation very disappointing. After several
days, I eventually gave up trying to append to a log file in Go. I just
couldn't figure it out. I also read a book on Go but it only covered reading
files.

~~~
mayanksinghal
It seems like [http://golang.org/pkg/os/#pkg-
constants](http://golang.org/pkg/os/#pkg-constants) has O_APPEND and searching
for 'Append file Golang' gives
[http://stackoverflow.com/questions/13513375/how-to-append-
te...](http://stackoverflow.com/questions/13513375/how-to-append-text-to-a-
file-in-golang) fairly on top.

~~~
ancarda
I got that, but actually writing to the file? What I'm looking for is
something like this: [http://msdn.microsoft.com/en-
us/library/ms143375.aspx](http://msdn.microsoft.com/en-
us/library/ms143375.aspx)

It covers everything you need to know. The MOST important part being
"example". I don't see any on Go's documentation. That just led me to being
frustrated. Also, I actually only see a list of functions and a very short,
vague description.

~~~
amatsukawa
I don't really know Go except for like 5 min of reading up on its syntax, so I
could be wrong, but this assertion that it was not obvious how to write to a
file in the documentation surprised me. So I clicked on the stackoverflow
link.

OpenFile returns type File from the signature.
[http://golang.org/pkg/os/#OpenFile](http://golang.org/pkg/os/#OpenFile)

Scanning through the methods (or doing a cmd + f search for "disk") has this
method
[http://golang.org/pkg/os/#File.Sync](http://golang.org/pkg/os/#File.Sync)

Method description says "Sync commits the current contents of the file to
stable storage. Typically, this means flushing the file system's in-memory
copy of recently written data to disk." Isn't that what you want?

Was it as clear as the C# example? Probably not. But I don't think this was
terribly hard to find. Code examples will come in time, as the language
matures.

IMO whether to put code examples into the documentation is really a choice by
the language maintainers. Lots of code examples can also clutter the docs. I
prefer to just have the docs tell me what each function does. If I really get
confused, I can google for examples. Java also doesn't really have code
examples right in the documentation, but they aren't hard to find because it's
been around for a long time. For example, Googling for "java code example how
to append to a file" and click on the first link.

~~~
thirsteh
Okay, it might not be totally obvious, but File implements io.Reader and
io.Writer (you can tell by the Read and Write methods.) Therefore, you can use
all the functions that take an io.Reader or io.Writer, i.e. all the functions
in [http://golang.org/pkg/io/](http://golang.org/pkg/io/) and
[http://golang.org/pkg/io/ioutil/](http://golang.org/pkg/io/ioutil/). It also
implements io.Closer (Close() method), which you can use to flush and close
the file when you're done.

It would probably be helpful if there was some kind of auto-generated list of
the known (or at least stdlib) interfaces a given type implements, even if you
don't actively declare it (like Java 'implements'.)

------
neya
If you come from a Scala background, you will find Go pretty 'Meh' feature-
wise (No offense). It's a great language, but still it has a long way to go.
With that said, I personally want Go to succeed as I love it's syntax
(compared to Scala's slightly hair-pulling syntax).

Also, the lack of robust battle-tested web-frameworks is right now a show
stopper for me.

~~~
PommeDeTerre
One interesting thing to consider about the increase in Go's popularity is
that it has been driven, to some extent, by programmers who really only had
experience with PHP, Ruby, or JavaScript.

These are the kind of developers who have by now been burned by the inherent
dangers and drawbacks of dynamic languages. They know enough to know that
there must be a better way to develop safer, more reliable and better-
performing software. They just aren't familiar enough with existing
statically-typed compiled languages to know what's already possible.

Go may just be in the right place at the right time. It is simpler than
languages like C, C++, Haskell, SML, and even Scala, for example. And it is
getting a lot of hype just when these dynamic language refugees need something
better, and are actively looking for it.

While it's good that Go offers a much better environment and infrastructure
than many of these developers are accustomed to, this may also be harmful in
some ways. It may be just "good enough", at least compared to the alternatives
that they're familiar with, that they don't feel the need to explore more
established languages which do offer much more.

Even if they don't move past Go any time soon, at least it's encouraging to
see them using a more responsible language for larger-scale software projects.

~~~
steveklabnik
This defiantly jives with some of my experiences. I've been saying that "Go
makes me feel like an old man," because other than a _fantastic_ development
experience, I don't actually see anything about Go that's particularly
interesting and/or worthwhile.

I also remind fellow Rubyists who say "Go is boring, it's supposed to be that
way!" that when they talk shit on Java, that was one of its rallying cries as
well.

It's all just a bunch of cycles, what's trendy comes and goes, is boring and
then interesting again...

------
norswap
For me, no exceptions is a show-stopper. I know people sometimes say it's
actually advantage, and I believe in some situation, it can be.

In a typical scenario, I might be working on an utility that does some IO. In
case of error, I just want to do some cleanup then exit. With exceptions, the
control flow will jump right up to the places were cleanup has to be
performed. With return values, I need to check return values at each step of
the call stack, which is tedious and ugly. Return values have to be modified
to account for error code. Admittedly, Go handles this last point well with
multiple return values.

~~~
mediocregopher
Go's version of 'finally' is called 'defer', and it can be used in any
situation, not just error management (I often use it for releasing locks in
the statement immediately after I've locked them).

>I need to check return values at each step of the call stack, which is
tedious and ugly.

I see it more as explicit. You HAVE to decide what you're going to do in case
of an error. Usually it's as simple returning that error, but sometimes you
want to do more, and having the question constantly being asked means you
think about it for all cases.

~~~
epidemian
> I see it more as explicit. You HAVE to decide what you're going to do in
> case of an error.

I've often read this argument, but i don't see how that is an advantage over
using exceptions.

With exceptions you don't _have_ to decide what to do in every function call
that might raise an error. You just have to know that they _can_ raise one,
and code accordingly. For example:

    
    
      f = File.open(...)
      foo(f)
      bar(f)
      f.close()
    

Is buggy if foo or bar could raise exceptions (the file would not be closed if
an exception is raised there). Fixing it could imply adding a `finally` block
around f.close() so the file always gets closed (same as Go's defer) or using
a higher order function that already does that for us:

    
    
      File.open(...) do |f|
        foo(f)
        bar(f)
      end
    

The thing is, this code didn't need to worry about which of foo or bar was
raising an error; it just needed to worry about closing the file if anything
went wrong. And i could add a new baz(f) call in there, or maybe refactor the
foo(f) and bar(f) calls into a foobar(f) function that does just that and the
code will still be as linear. There'd be no need to add extra `if`s there nor
in the refactored foobar(f) function.

> Usually it's as simple returning that error...

I'd say that it's rather "most of the time" than "usually". And exceptions
give you exactly that default behaviour of propagating the error up the stack.
Without having to obfuscate the logic of some intermediate code (that doesn't
care about what error could happen, as long as they are propagated to the
caller) with superfluous `if`s and `return`s.

~~~
pdonis
We had a HN thread some time ago about this issue:

[https://news.ycombinator.com/item?id=4562211](https://news.ycombinator.com/item?id=4562211)

I agree with your take on it; I blogged about it at the time that previous HN
thread came up:

[http://blog.peterdonis.com/rants/python-v-go-error-
handling....](http://blog.peterdonis.com/rants/python-v-go-error-
handling.html)

------
samnardoni
When programming for fun in my spare time, I've noticed that I use Go
differently from certain other languages (Haskell, Rust).

When writing Haskell, I spend a lot of time thinking about how I can express
the problem using the different language constructs, and how elegant the code
is. With Go, because the language is so simple, I just focus on solving the
problem; I almost feel that I solve the problem in spite of the language.

------
khyryk
Go is interesting and I use it from time to time, but I'd hesitate to call it
excellent without runtime constants and generics. Also, the "and not used"
errors can get annoying.

------
dustingetz
quick summary:

    
    
        * no coding style flamewars
        * it has familiar syntax
        * builtin concurrency model
        * it has gc
        * it is fast
        * static types that don't get in the way
    

If you compare this list to popular up-and-coming ecosystems from the 90s
(java, python, C, C++, Ruby), okay, concurrency is a big win and everything
else, maybe go is a little bit better.

If you compare to other popular up-and-coming ecosystems in 2013 that have a
similar sized following as Go (Scala, Clojure, Haskell, Node, Rust)...

Well, at least Go beats Node. and Haskell appeared in 1990.

~~~
enneff
If you're going to summarize, don't leave out the entire section on the tool
chain. Jeeze.

------
harrytuttle
Pretty much my view on the subject.

One thing I'd really like to see for go is a UI toolkit which is native to it.
Not Qt, Gtk, Wx ports, but a proper high level UI framework like WPF (but
not!). I reckon that would take it into the financial and business sectors in
no time at all.

That and dynamic loading at runtime.

~~~
frozenport
Financial has been largely moving to Java (looking at Goldman Sachs), so I
don't see them switching anytime soon.

Qt is a fine framework and I see little reason to reinvent the wheel.

~~~
thirsteh
Finance firms that are migrating are going to functional languages anyway--
OCaml, F#, ...

~~~
bsg75
Is there actually much of a trend _to_ OCaml?

~~~
thirsteh
Probably more from OCaml to F# now.

------
gutsy
I'm a Java guy and I've been learning Go on the side just for fun and so far I
like it. I've found the documentation fairly easy to get through (the fact
that there are examples right in the documentation makes me like it better
than Java).

I don't think the language is perfect, but I think it's well on it's way to
getting there.

