10 ms·

Go (lang): one year ago today

85 points by fogus 16y ago

Jabbles 16y 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 16y 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 http://lambda-the-ultimate.org/node/3896
  - dlsspy 16y 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.
    - nickik 16y ago
      I still think go is as it is because the want as many C/C++ Programmers as possible. They could have done a better language (it is ok already) but probebly a less successful one (to bad C++ and Java messed up most programmers).
  - krakensden 16y 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.
    - masklinn 16y ago
      > On the other hand, the academic community seems to have a fairly narrow outlook on programming language design. That's a joke right?
      - nl 16y ago
        I don't think it's a joke. The academic community is - almost by definition - focused on doing "new stuff". That means, for example that they have a significant focus on getting type systems correct, but often consider things like integration with existing 3rd party libraries uninteresting. You'd never see a language like Perl, PHP, or even Javascript come from the academic community because they don't break any new ground.
        uriel 16y ago
        > You'd never see a language like Perl, PHP, or even Javascript come from the academic community And you certainly will never see language like C come from academia. Nor an operating system like (the original) Unix.
        radq 16y ago
        Weren't both C and Unix innovative at the time?
        dagw 16y ago
        Not really, at least not from an academic point of view. C showed up a few years after languages like LISP and Simula and around the same time as Prolog. Those languages are far more innovative than C. C on the other hand basically took well known concepts from BCPL and PDP Assembly and improved on them and made them portable. Unix was basically a simpler, easier to use version of MIT Multics, designed for the smaller and cheaper PDP-7. Most of the innovative ideas in Unix had first implemented in Multics. So while neither C nor Unix where truly innovative, even for their time, they won out because they took well known concepts and actually made them work in a practical sense.
  - goalieca 16y 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.
    - shadowfox 16y ago
      Are you a programming language researcher?
      - deleted 16y ago
        [deleted]
    - olliesaunders 16y ago
      Maintenance is absolutely on the radar of the academics who designed Haskell.
  - Jabbles 16y 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.
    - wmf 16y ago
      Some people have used OCaml for systems work, and it's a lot more "advanced" in a programming language theory sense. BitC also looks more ambitious than Go.
      - scott_s 16y ago
        That's the problem with designing and implementing an ambitious programming language: it's harder. Which is one of the reasons that Go is being used to develop real applications. I don't think the same thing can be said for BitC. I do think OCaml is an interesting point.
        mavelikara 16y ago
        > Which is one of the reasons that Go is being used to develop real applications. I don't think the same thing can be said for BitC. Until BitC author claims that it is used for real applications. Has anyone outside of the Go team mentioned any use of Go in real applications? Please correct me if I am wrong, but at the moment Go, BitC and Rust are all experimental systems programing languages.
        wmf 16y ago
        "Internally at Google there are several teams that choose Go for building production software"
        mavelikara 16y ago
  - mhd 16y ago
    Niklaus Wirth would disagree. (I know, he would probably disagree with Pike, Thompson et al., too, but on different principles.)
  - shadowfox 16y ago
    You should also note the responses to this comment on that thread including the one from the author :)
  - uriel 16y ago
    "programming language researchers" are starting to sound more and more like "string theory researchers".
  - rdtsc 16y 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.
  - silentbicycle 16y ago
    I don't think Z-bo speaks for everyone at LtU. His or her comments often strike me as a bit troll-ish.
    - olliesaunders 16y ago
      If you read on, on LtU, someone suggests that they discuss Go on its own merits instead of making statements about the hiring practices of Google and Z-bo agrees.
  - konad 16y ago
    Pike, Ritchie and Cox, those simple fools
- dlsspy 16y 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 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 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.
Detrus 16y 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 16y ago
  What do you think needs cleaning up?
  - Detrus 16y ago
    Aesthetics for starters. CoffeeScript http://jashkenas.github.com/coffee-script/ 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++.
    - Jabbles 16y ago
      IMO: I love capitalised public method names. It means I can immediately tell whether a method is public or private, in any context, e.g. on code pasted on HN. look.Like().A().Mess() looks awful. Don't do it. Or do, it's up to you/ your company's style guide. You could easily avoid chained methods entirely. Go is at the opposite end from Ruby. It's a systems language... The fact that they look different is no surprise. func([] byte T* blah) - that's not Go. send and receive are perfectly intuitive to me. Watch! You put it in the channel<-. You get it out of the <-channel. There is no "->". "in general the syntax is itsy bitsy" - I can only suggest you try it for a bit longer until you get used to it.
SoftwareMaven 16y 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 16y ago
  No but it does has insignificant white space - the language doesn't care but you are free to argue about it.
  - uriel 16y ago
    It also has gofmt which neatly takes care of pretty much any such arguments.
tav 16y 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 16y 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?
  - tav 16y 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.
spyne-02139 16y 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 16y ago
  FTA: > We’re also exploring some further additions to the type system to make generic programming easier.
- jamesaguilar 16y 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 16y ago
    Yes, Haskell IRC activity pattern is different: http://www.cse.unsw.edu.au/~dons/irc/ http://www.cse.unsw.edu.au/~dons/irc/ Compare also: http://gmane.org/plot-rate.php?group=gmane.comp.lang.go.general http://gmane.org/plot-rate.php?group=gmane.comp.lang.go.gene... http://gmane.org/plot-rate.php?group=gmane.comp.python.general http://gmane.org/plot-rate.php?group=gmane.comp.python.gener... http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell.cafe http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell...

85 points by fogus 16y 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 16y 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 http://lambda-the-ultimate.org/node/3896
- dlsspy 16y 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.
  - nickik 16y ago
    I still think go is as it is because the want as many C/C++ Programmers as possible. They could have done a better language (it is ok already) but probebly a less successful one (to bad C++ and Java messed up most programmers).
- krakensden 16y 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.
  - masklinn 16y ago
    > On the other hand, the academic community seems to have a fairly narrow outlook on programming language design. That's a joke right?
    - nl 16y ago
      I don't think it's a joke. The academic community is - almost by definition - focused on doing "new stuff". That means, for example that they have a significant focus on getting type systems correct, but often consider things like integration with existing 3rd party libraries uninteresting. You'd never see a language like Perl, PHP, or even Javascript come from the academic community because they don't break any new ground.
      - uriel 16y ago
        > You'd never see a language like Perl, PHP, or even Javascript come from the academic community And you certainly will never see language like C come from academia. Nor an operating system like (the original) Unix.
        radq 16y ago
        Weren't both C and Unix innovative at the time?
        dagw 16y ago
        Not really, at least not from an academic point of view. C showed up a few years after languages like LISP and Simula and around the same time as Prolog. Those languages are far more innovative than C. C on the other hand basically took well known concepts from BCPL and PDP Assembly and improved on them and made them portable. Unix was basically a simpler, easier to use version of MIT Multics, designed for the smaller and cheaper PDP-7. Most of the innovative ideas in Unix had first implemented in Multics. So while neither C nor Unix where truly innovative, even for their time, they won out because they took well known concepts and actually made them work in a practical sense.
- goalieca 16y 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.
  - shadowfox 16y ago
    Are you a programming language researcher?
    - deleted 16y ago
      [deleted]
  - olliesaunders 16y ago
    Maintenance is absolutely on the radar of the academics who designed Haskell.
- Jabbles 16y 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.
  - wmf 16y ago
    Some people have used OCaml for systems work, and it's a lot more "advanced" in a programming language theory sense. BitC also looks more ambitious than Go.
    - scott_s 16y ago
      That's the problem with designing and implementing an ambitious programming language: it's harder. Which is one of the reasons that Go is being used to develop real applications. I don't think the same thing can be said for BitC. I do think OCaml is an interesting point.
      - mavelikara 16y ago
        > Which is one of the reasons that Go is being used to develop real applications. I don't think the same thing can be said for BitC. Until BitC author claims that it is used for real applications. Has anyone outside of the Go team mentioned any use of Go in real applications? Please correct me if I am wrong, but at the moment Go, BitC and Rust are all experimental systems programing languages.
        wmf 16y ago
        "Internally at Google there are several teams that choose Go for building production software"
        mavelikara 16y ago
- mhd 16y ago
  Niklaus Wirth would disagree. (I know, he would probably disagree with Pike, Thompson et al., too, but on different principles.)
- shadowfox 16y ago
  You should also note the responses to this comment on that thread including the one from the author :)
- uriel 16y ago
  "programming language researchers" are starting to sound more and more like "string theory researchers".
- rdtsc 16y 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.
- silentbicycle 16y ago
  I don't think Z-bo speaks for everyone at LtU. His or her comments often strike me as a bit troll-ish.
  - olliesaunders 16y ago
    If you read on, on LtU, someone suggests that they discuss Go on its own merits instead of making statements about the hiring practices of Google and Z-bo agrees.
- konad 16y ago
  Pike, Ritchie and Cox, those simple fools
dlsspy 16y 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 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 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.

Detrus 16y 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 16y ago
What do you think needs cleaning up?
- Detrus 16y ago
  Aesthetics for starters. CoffeeScript http://jashkenas.github.com/coffee-script/ 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++.
  - Jabbles 16y ago
    IMO: I love capitalised public method names. It means I can immediately tell whether a method is public or private, in any context, e.g. on code pasted on HN. look.Like().A().Mess() looks awful. Don't do it. Or do, it's up to you/ your company's style guide. You could easily avoid chained methods entirely. Go is at the opposite end from Ruby. It's a systems language... The fact that they look different is no surprise. func([] byte T* blah) - that's not Go. send and receive are perfectly intuitive to me. Watch! You put it in the channel<-. You get it out of the <-channel. There is no "->". "in general the syntax is itsy bitsy" - I can only suggest you try it for a bit longer until you get used to it.

SoftwareMaven 16y 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 16y ago
No but it does has insignificant white space - the language doesn't care but you are free to argue about it.
- uriel 16y ago
  It also has gofmt which neatly takes care of pretty much any such arguments.

tav 16y 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 16y 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?
- tav 16y 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.

spyne-02139 16y 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 16y ago
FTA: > We’re also exploring some further additions to the type system to make generic programming easier.
jamesaguilar 16y 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 16y ago
  Yes, Haskell IRC activity pattern is different: http://www.cse.unsw.edu.au/~dons/irc/ http://www.cse.unsw.edu.au/~dons/irc/ Compare also: http://gmane.org/plot-rate.php?group=gmane.comp.lang.go.general http://gmane.org/plot-rate.php?group=gmane.comp.lang.go.gene... http://gmane.org/plot-rate.php?group=gmane.comp.python.general http://gmane.org/plot-rate.php?group=gmane.comp.python.gener... http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell.cafe http://gmane.org/plot-rate.php?group=gmane.comp.lang.haskell...