Go (lang): one year ago today

http://blog.golang.org/2010/11/go-one-year-ago-today.html

by fogus • 16 years ago

85 70 16 years ago

blog.golang.org

Jabbles4• 16 years ago

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• 16 years ago

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

dlsspy2• 16 years ago

I definitely had plenty of complaints (there's no way in the language to detect when a process exits, for example -- though you can at least build one yourself).

I don't think LtU approval is necessary to have done something good. We need more tools that help programmers solve problems of concurrency without losing their feet.

Tools that aren't entirely groundbreaking are very useful here, because you can take a guy who knows only c++ and have him write a bit of go. I can't as easily get him to use twisted or erlang or even node.js.

krakensden• 16 years ago

On the other hand, the academic community seems to have a fairly narrow outlook on programming language design. Go seems to be more concerned with ergonomics than provability, which seems like a reasonable decision from where I stand.

goalieca• 16 years ago

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.

Jabbles4• 16 years ago

Interesting quote. But since Go is meant to be a "systems language", and the (only?) others are C and C++, which first appeared in 1972 and 1983 respectively, I can confidently assert that "modern language design techniques" are not all they're cracked up to be.

Moreover, I care not one whit that Google looks "really bad and unattractive to programming language researchers"; because I'm not one.

mhd• 16 years ago

Niklaus Wirth would disagree.

(I know, he would probably disagree with Pike, Thompson et al., too, but on different principles.)

shadowfox2• 16 years ago

You should also note the responses to this comment on that thread including the one from the author :)

uriel4• 16 years ago

"programming language researchers" are starting to sound more and more like "string theory researchers".

rdtsc• 16 years ago

Let's not forgot that academia also produced Go!. You know, the other Go!, that only became known after Go appeared, because it has a similar name.

silentbicycle2• 16 years ago

I don't think Z-bo speaks for everyone at LtU. His or her comments often strike me as a bit troll-ish.

konad• 16 years ago

Pike, Ritchie and Cox, those simple fools

dlsspy2• 16 years ago

I used go recently when I needed to write a test case when trying to exploit a specific suspected bug. https://github.com/dustin/gohammer

It was successful in that I found it very easy to express what I wanted and make a concurrent app to do it. It didn't actually find a bug (I'm not entirely sure there was one, but the code that fell out of it is reusable for my next one).

When go first came out, I wrote a memcached server in it: http://dustin.github.com/2009/11/12/gomemcached.html -- the language was a little rougher when I started the project (defer didn't work properly until last march), but I still feel pretty good about it.

Detrus5• 16 years ago

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.

supersillyus• 16 years ago

What do you think needs cleaning up?

Detrus5• 16 years ago

Aesthetics for starters. CoffeeScript http://jashkenas.github.com/coffee-script/ is what modern syntax should look like. White space instead of the bracket mess.

Go's public/private difference is capitalization of method names. That's hard to scan. Then you get chains that look.Like().A().Mess().

What the Go team seemed to do was take syntax from other languages they were familiar with, ugly syntax non-dynamic languages. They didn't focus on it, Pike said it wasn't important, semantics are important. So when you don't design syntax first, you get a syntax that's on the opposite end from Ruby.

Arguments func([] byte T* blah), who knows what goes where. That needs work.

The c-> and <-c is unintuitive, the syntax is so itsy bitsy it's easy to miss the difference. They should have keywords for that.

And in general the syntax is itsy bitsy, they feel that shorter words means quicker to read, but it's an overreaction to never ending lines commonly found in Java and C++.

masklinn3• 16 years ago

> Hopefully with people from the dynamic languages camp trying the language they'll clean up the syntax.

Considering the year elapsed, that's about as likely as them killing the project and admitting that Go is a turd which only gets airwave because it's a project by two extremely famous googlers. The syntax is crap, the type system is garbage, they spend their time reinventing utterly terrible wheels and they've thrown out basically all ideas of safety they could get on fire.

KaeseEs• 16 years ago

I agree that the Go example code looks ugly, although much of that for me is simply from their ideas on capitalization. Of special note from my perspective is that their biggest attempt to clean up syntax, by adopting a JS-esque automatic insertion of most semicolons, has backfired: it doesn't make anything prettier, it's either a wash or a slight loss with respect to obviousness of code, and it introduces a few opportunities for bugs. Perl of all languages did a better job at this goal by just making the terminator of the last element of a block or list optional.

I appreciate their maintenance of an end delimiter to blocks that is vertically aligned with the start of the block, although they could have gotten a bigger win imo by going with the ALGOL/Ruby style 'end' rather than the C style curly brace (and in doing so freed up curly braces to unambiguously be used for something else).

koenigdavidmj• 16 years ago

Yeah, that was likely a big mistake on their part.

Arguments on significant whitespace aside, I think that this is one thing that Python got right. (For reference, Python's rules are that ending a line with a backslash will continue a statement, and the same effect will occur automatically if you have a parenthesis, curly, or bracket open.)

I might also be convinced that it would be a good idea to have statement continuation happen if the last token on a line was a binary operator, for the benefit of code like:

    if self.foo() and
           self.bar() and
           self.baz():
        do stuff

(Currently PEP 8 requests that you put parentheses around the test.)

chunkbot• 16 years ago

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.

Detrus5• 16 years ago

It fades away, but lags there chipping at productivity. The Ruby crowd makes a big fuss about their syntax, talk about how it revitalized their love of programming, makes programming enjoyable and so on. They might be onto something.

silentbicycle2• 16 years ago

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.

mfukar• 16 years ago

Doubt it. I learned Prolog in 1 week, the syntax is mighty simple and usable.

I'm still foggy on Erlang, however, and less motivated every time I refer to documentation (but hey, I'm getting paid for it so it kind of evens out).

SoftwareMaven• 16 years ago

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• 16 years ago

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

uriel4• 16 years ago

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

tav2• 16 years ago

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• 16 years ago

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?

tav2• 16 years ago

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.

olliesaunders3• 16 years ago

Is interop with C an important thing? Isn't Go supposed to replace the need for C. Is it just because Go's compilers aren't mature enough yet that you still need to drop back to C in places?

asb• 16 years ago

It's important for the ability to use existing C libraries.

spyne-02139• 16 years ago

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.

patrickaljord• 16 years ago

FTA:

> We’re also exploring some further additions to the type system to make generic programming easier.

jamesaguilar2• 16 years ago

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• 16 years ago

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.python.gener...

http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell...

whyenot• 16 years ago

Use larger bins (by week or month), and I think your results would look a lot less dismal.

Go (lang): one year ago today

Related Stories