
Go (lang): one year ago today - fogus
http://blog.golang.org/2010/11/go-one-year-ago-today.html
======
tav
Having bet my entire startup on Go, I am really thankful for the steady, but
measured, improvements to the language. It's been a real pleasure to work
with.

It may not be as beautiful as CoffeeScript (which we also use), as rich as
Python, as safe as Rust, as concurrent as Erlang, or even as hackable as Ruby,
but it certainly offers an unparalleled set of features which is hard to find
in just one language — decent standard library, decent syntax, decent
performance, super easy concurrency, a helpful and reasonably sized developer
community, a relative level of stability, automatic memory management with
good enough control over memory use, usable interoperability with C, native
client support and even a standard testing framework.

Thank you and happy birthday to all the fellow Go developers out here on HN.

~~~
stuartloxton
Although I have used Go in the past and do like it - thought I would just
point out that nearly every positive about Go you mentioned had 'Good enough'
prefix it. Are you actually finding Go good or only enough for your current
needs?

As a question: do you see parts of your startup expanding past the area of Go?
Would a mixture of other languages help?

~~~
tav
Great question Stuart. I'd first like to say that in today's environment, it
would be insane not to take advantage of a mixture of languages. If you have
the expertise within your team, you should definitely leverage the strengths
of the various language eco-systems. We've been developing an RPC-like system
(think ZeroMQ meets BERT-RPC) so that services can be written in whatever
language is most suitable — Go, Python, Ruby, CoffeeScript, Java — and our
datastore core is written in C. Hell, we're even working on our own object-
capability language using PyPy's translation toolchain.

But, having said all that, the biggest surprise has been how Go has become the
dominant language within our code base. We initially started using Go to just
handle the networking layer. But it soon became apparent that Go was perfectly
viable as a general purpose language. And today the majority of our code is
written in Go.

So, whilst we'll continue to leverage other languages for what they are good
at, I can confidently say that Go will be at the heart of our technology stack
for the forseeable future. And with the various "good enough" statements, I
was trying to say that although Go is not the best language ever for specific
features (e.g. syntax, standard library, etc.), it definitely offers the best
all round set. And the situation only gets better every day. So I'll
definitely say that Go is more than good enough.

------
Jabbles
It continues to amaze me how much is packed into the Go language. It's not
perfect, but the language specification is something that you can easily read
in one go; something that is impossible for languages like C++. This results
in more intuitive behaviour and, in my limited experience, fewer bugs.

I hope other language designers take note of Go and put more emphasis on
simplicity in the future.

I would also be very interested to know which companies are using Go, and for
what.

~~~
barrkel
A relevant quote from a (relatively academic, static typing-oriented,
functional etc.) sector of the language design community:

 _Google is hiring people to design languages and tools that know absolutely
nothing about modern language design techniques, or what modern software
engineering tools look like._

 _If you're paying any attention at all to Go, you're not learning anything.
In fact, it's possible you're damaging your brain. It's projects like these
that make Google look really bad and unattractive to programming language
researchers, especially as compared to Adobe, IBM, Sun, and Microsoft._

From here: <http://lambda-the-ultimate.org/node/3896>

~~~
goalieca
Hahaha. I'm an academic but I still laugh because we are so horribly arrogant
and yet quite oblivious. We always introduce our papers and grants with "this
is a very important problem with applications in blah blah blah" but we
honestly have no idea what that really means or if it actually is the big
problem for engineers (as opposed to an annoyance) and go on to do present our
work developed in a bubble and tested on whatever we have access to in our
labs. Consider erlang, such a language would never come out of academia. It's
far too focused on reliability and maintenance. Those two problems are never
on our radar in any real way.

~~~
shadowfox
Are you a programming language researcher?

------
SoftwareMaven
From the tutorial: "The language forces the brace style to some extent."

Well, that's it. If I can't have a brace-war tearing the dev group apart for
months and kill productivity, I want nothing to do with that language. What's
next, significant white space?

~~~
iuyhgttg
No but it does has insignificant white space - the language doesn't care but
you are free to argue about it.

~~~
uriel
It also has gofmt which neatly takes care of pretty much any such arguments.

------
Detrus
Hopefully with people from the dynamic languages camp trying the language
they'll clean up the syntax. It's ugly and makes a lot of the example code
hard to read.

~~~
chunkbot
Syntax is never _really_ a problem. We do a lot of work in Erlang...

 _Erlang is based originally on Prolog, a logic programming language that was
briefly hot in the 80's. Surely you've seen other languages based on Prolog,
right? No? Why not? Because Prolog sucks ass for building entire applications.
But that hasn't deterred Erlang from stealing it's dynamite syntax._ [source:
<http://damienkatz.net/2008/03/what_sucks_abou.html> _What Sucks About Erlang_
]

In reality, syntax just fades away after ~5 minutes of real world usage. As
Steve Jobs would say, it's not that big of a deal.

~~~
silentbicycle
Erlang's syntax isn't representative of Prolog's. It was originally
implemented in SICStus, sure, but Prolog lets you add your own operators, and
Erlang added a ton on top of the (rather clean) Prolog syntax. How would Ruby
(or whatever syntax you like) look if you made a DSL _by adding every operator
that wasn't already in use?_

You know all the problems with the ambiguous ; , . stuff that Katz gripes
about in that post? Prolog terminates every clause with a period, and all
related rules just occur in sequence. Prolog has a read function, much like
read in Lisp - "read the next complete (s-expression|Prolog clause) from
stdin". The original Erlang compiler needed to read all of the alternative
clauses for a function in one go* , so they strung them together with "," and
";", which are Prolog's _and_ and _or_ operators. (They could have fixed this
when they started self-hosting, but probably had other priorities.) In
practice, it isn't a problem (and Erlang has many perks to make up for those
minor syntactic irritations!), but that can't be blamed on Prolog. It's sort
of like if you used Lisp's (read) to load more expressions, but since your
compiler needed you to read a whole module at once as an implementation
detail, you used [ and { pairs instead of parens. Yuck!

In Prolog, that sort of code looks like this:

    
    
        parent(terach, abraham).
        parent(abraham, isaac).
        parent(isaac, jacob).
        parent(jacob, benjamin).
    

Note the conspicuous lack of semicolons.

* I'm reading between the lines here, so if Robert Virding swoops in and tells me I'm wrong, _Hello Robert!_ :)

If anything, the reason that Prolog isn't good for entire applications is that
it's fundamentally a rules/database query language. It's awkward for stateful
/ procedural code, but if you treat it like (say) a much more sophisticated
SQLite, it will be good to you.

------
spyne-02139
If IRC activity correlates to interest in the language, then data shows a
bleak picture of interest in go-lang. Here is the total character count per
day as a percentage of the activity on November 12, 2009.

    
    
      http://i.imgur.com/8ERaf.png
    
      X axis is days (approx) since 11/12/09
      Y is % of chars as compared with the busiest day (11/12/09)
    

I've used the language for big projects and little projects. The strict error
handling is fantastic. I like everything about the language except one thing.
Just one, and it's a big nasty thing. I hope Russ, Rob, Iant or someone from
the development team reads this, because it needs to be said, and others have
said it, and it's the reason I stopped programming in go. Go might not need
generics, the go development team might not need generics, but I DO! You
wonder why there isn't a rocking go web framework? Because generics would be a
huge help and no one wants to piece together a tedious solution immediately
deprecated by the announcement we've been waiting a year for, "Go is getting
generics!" All I want for christmas is generics ... and a pony.

~~~
jamesaguilar
Nah, the interest for new things from big companies always peaks shortly after
the announcement. If you cut off the outliers e.g. before day 45 then this
graph would look much rosier. Or, to put it another way, would the graph for
any successful language like Python or C look any different in the first year
after the initial announcement?

~~~
SRG
Yes, Haskell IRC activity pattern is different:

<http://www.cse.unsw.edu.au/~dons/irc/>

Compare also:

[http://gmane.org/plot-
rate.php?group=gmane.comp.lang.go.gene...](http://gmane.org/plot-
rate.php?group=gmane.comp.lang.go.general)

[http://gmane.org/plot-
rate.php?group=gmane.comp.python.gener...](http://gmane.org/plot-
rate.php?group=gmane.comp.python.general)

[http://gmane.org/plot-
rate.php?group=gmane.comp.lang.haskell...](http://gmane.org/plot-
rate.php?group=gmane.comp.lang.haskell.cafe)

~~~
jamesaguilar
Those languages were all quite old and popular by the time those graphs
started. It's not apples-to-apples to compare languages with a decade or more
of use to a language whose inception was a year ago.

