8 ms·

New stable release of Go

129 points by uriel 15y ago

lobster_johnson 15y ago
I haven't used Go het, but try to keep up to date. One issue I have is that naming conventions seem all over the place. Is there a logic behind the naming of things? For example, function names are sometimes CapitalizedLikeThis, but sometimesLikeThis. This kind of messy inattention to detail makes the language come across as sloppy and unfinished.
- kaib 15y ago
  This is actually part of the language. Identifiers starting with a capital letter are exported outside the package, the ones with a lower case letter are not.
- uriel 15y ago
  This is covered in the basic language introduction: names starting with a capital letter are public, names starting in lower case are private. Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better).
  - 198d 15y ago
    Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better). Do you mind explaining this statement a little further, specifically related to Python and Ruby. I work with both of those languages and find the naming conventions to be quite clean and respected. The style of the language is not enforced, but you'll certainly be chastised by any serious developer in either language for doing something outside the norm.
    - uriel 15y ago
      The Python stdlib is full of examples of CamelCase, under_score and alltogether. In Ruby just looking at the methods for strings is enough to find this like: "instance_variable_defined?", "rindex", "tr_s", "casecmp", "equal?", "eql?" and more. Yes, it is all lower case, but consistent it is certainly not.
      - lepht 15y ago
        I also find myself wishing that Ruby's destructive (!) and boolean (?) suffixes were either enforced somehow or not used at all. The idea itself is cool, communicating extra context about what the method does or its intended usage, but they're used so inconsistently (even withing the Ruby stdlib) that A) They're unreliable and you need to check the source to find out the behavior anyway and B) It's less predictable whether the method exists with the suffix or without, so you need to either run it and modify your method call if there's an error or check the lib/API docs. This is the sort of thing that makes having an IDE handy for completing method names, which is unfortunate because Ruby is generally very usable without any IDE crutches.
  - lobster_johnson 15y ago
    I see. I applaud new ideas, but personally I find Go's choice visually jarring; on the screen it ends up looking like a train wreck: fmt.Printf(colorizeWithAnsi(strings.Replace(s, " ", "/", -1)); It goes from being mere syntax (like Ruby's elegant use of '@' to denote instance variables) to screwing with the names themselves apparently just to avoid introducing keyword (like Java's 'public') or additional syntax for exporting symbols.
- leon_ 15y ago
  Like the other commenter said: Functions/Fields in structs that start with a capital letter are visible to other packages. Functions starting with lower case letters are like C static and fields are (package) private. I'm not perfectly happy with this convention because I prefer the everything_lower_case_with_underscores style but you get used to it. Go's benefits out weight its awkward quirks by far.
kaib 15y ago
This is actually the first proper stable release since the process was introduced, the first tagged release did not go through a similar release preparation. I'm personally extremely happy with this development. We run Tinkercad on a moderately complex Go/C++ based server infrastructure (7 server types on tens of machines) and we have been lagging the Go tip given our need to avoid instability. The fact that we can now sync more often than 6 months and with less risk is great. It's a important step towards making Go a solid choice for distributed systems programming.
leon_ 15y ago
Go replaced python for me. Today morning for example I wrote a utility/demon that controls my Macbook Pros's Fan under Linux (because out of the box the fan stays @ 2000rpm till somewhere around ~80C). I've also written 2 smaller web apps using Go and I had really fun doing so. Statically typed language for webdev = <3 I can say I became a Go fanboy in the last few weeks and I hope Go gets more traction. Go @ Android would be freaking awesome.
- singular 15y ago
  go already targets arm, android can't be too far away.
  - uriel 15y ago
    Also Brad Fitzpatrick (of LiveJournal and memcached fame) recently moved from the Android team to the Go team. Go on Android should be quite cool, but what will be awesome is Go on AppEngine.
    - singular 15y ago
      yeah I noticed him on the team. The core team has some amazing people on it, including famous people Rob Pike (Bell Labs unix/plan 9 guy) and Brad. I think that's a good sign that google are quite ambitious about the language :)
      - uriel 15y ago
        It is an amazing team, but the rest pales beside ken ('Unix guy' doesn't begin to do him justice).
        singular 15y ago
        Don't get me wrong, I didn't mean to downplay his achievements - The guy is a legend. I'm British. I was being understated :)
    - 15y ago
timclark 15y ago
Reasons to like go: gofmt - no need to argue over coding style since it is enforced by this tool. gofix - as the language evolves, the go team provide fixes that you can run across your old source code automatically.
- munificent 15y ago
  If you look at the actual fixes gofix provides, most of them are to paper over a lack of language features. In particular, if Go supported function overloading, they probably wouldn't need gofix at all.
  - uriel 15y ago
    Some people consider the lack of function overloading a feature. And languages that have function overloading have plenty of API changes that could benefit from something like gofix.
  - supersillyus 15y ago
    I disagree. Even for the gofix fixes look to be simple "n args to n-1 args" changes, even in a language that supports function overloading I would prefer to have one version of the function, not two. The use of overloading to avoid the pain of an API change over time leads to a pretty crappy interface.
  - jff 15y ago
    "If they just had function overloading, we could keep dozens of old, unmaintained functions around forever! Think how amazing documentation will be!"
    - pjscott 15y ago
      As it is, their core libraries are remarkably clean and well-designed. The source code is even a pleasure to read.
      - munificent 15y ago
Kilimanjaro 15y ago
Now all we need is Go on AppEngine. Killer.
swannodette 15y ago
What's the appeal of Go when something like OCaml exists and seems to cover much of the same territory and delivers better performance? Not trolling here, I'm genuinely curious.
- uriel 15y ago
  First of all, it is quite obvious that Go and OCaml are completely different languages designed around very different philosophies and styles. Also saying that you are not trolling doesn't make your comment any less trollish, specially given that your only claim is false, Go, despite still being much younger and greatly unoptimized is already considerably faster than OCaml: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=ocaml http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
  - swannodette 15y ago
    I'm asking about technical merits of one over the other, which you didn't respond to at all. And look at the overall scores on the 64bit one-core and quad-core benchmarks. OCaml is ahead.
    - chc 15y ago
      I'm looking at the overall scores on the 64-bit single-core and Go is six places ahead of OCaml. On the 64-bit quad, Go is five places ahead. The only one where OCaml appears to come close is single-core 32-bit, in which Go comes out one place ahead of OCaml. (And just so we're clear: I actually like OCaml and have never used Go. So I'm not trying to wave some Go fanboy flag or anything. Those are just the numbers.)
      - swannodette 15y ago
        http://shootout.alioth.debian.org/u64q/which-language-is-best.php http://shootout.alioth.debian.org/u64q/which-language-is-bes... http://shootout.alioth.debian.org/u64/which-language-is-best.php http://shootout.alioth.debian.org/u64/which-language-is-best...
icey 15y ago
Is there any sort of "Planet" for Go? (i.e. http://planet.lisp.org/ http://planet.lisp.org/, http://planet.python.org/ http://planet.python.org/, http://www.planetscala.com/ http://www.planetscala.com/, http://planetcsharp.com/ http://planetcsharp.com/ etc?)
- bockris 15y ago
  http://www.gophertimes.com/ http://www.gophertimes.com/ ?
  - timclark 15y ago
    Well worth reading!
- uriel 15y ago
  http://planet5.cat-v.org/ http://planet5.cat-v.org/ is the closest, but haven't maintained it properly for a while, I should add a few new blogs and remove some that are obsolete.
  - deleted 15y ago
    [deleted]
  - smosher 15y ago
    ichi ni san shi Go.

129 points by uriel 15y ago

I haven't used Go het, but try to keep up to date. One issue I have is that naming conventions seem all over the place. Is there a logic behind the naming of things? For example, function names are sometimes CapitalizedLikeThis, but sometimesLikeThis. This kind of messy inattention to detail makes the language come across as sloppy and unfinished.

kaib 15y ago
This is actually part of the language. Identifiers starting with a capital letter are exported outside the package, the ones with a lower case letter are not.
uriel 15y ago
This is covered in the basic language introduction: names starting with a capital letter are public, names starting in lower case are private. Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better).
- 198d 15y ago
  Go's naming conventions are much more clean, respected and even enforced than in almost any other language I know (Ruby and Python are specially bad in this, but C++ and Java are not much better). Do you mind explaining this statement a little further, specifically related to Python and Ruby. I work with both of those languages and find the naming conventions to be quite clean and respected. The style of the language is not enforced, but you'll certainly be chastised by any serious developer in either language for doing something outside the norm.
  - uriel 15y ago
    The Python stdlib is full of examples of CamelCase, under_score and alltogether. In Ruby just looking at the methods for strings is enough to find this like: "instance_variable_defined?", "rindex", "tr_s", "casecmp", "equal?", "eql?" and more. Yes, it is all lower case, but consistent it is certainly not.
    - lepht 15y ago
      I also find myself wishing that Ruby's destructive (!) and boolean (?) suffixes were either enforced somehow or not used at all. The idea itself is cool, communicating extra context about what the method does or its intended usage, but they're used so inconsistently (even withing the Ruby stdlib) that A) They're unreliable and you need to check the source to find out the behavior anyway and B) It's less predictable whether the method exists with the suffix or without, so you need to either run it and modify your method call if there's an error or check the lib/API docs. This is the sort of thing that makes having an IDE handy for completing method names, which is unfortunate because Ruby is generally very usable without any IDE crutches.
- lobster_johnson 15y ago
  I see. I applaud new ideas, but personally I find Go's choice visually jarring; on the screen it ends up looking like a train wreck: fmt.Printf(colorizeWithAnsi(strings.Replace(s, " ", "/", -1)); It goes from being mere syntax (like Ruby's elegant use of '@' to denote instance variables) to screwing with the names themselves apparently just to avoid introducing keyword (like Java's 'public') or additional syntax for exporting symbols.
leon_ 15y ago
Like the other commenter said: Functions/Fields in structs that start with a capital letter are visible to other packages. Functions starting with lower case letters are like C static and fields are (package) private. I'm not perfectly happy with this convention because I prefer the everything_lower_case_with_underscores style but you get used to it. Go's benefits out weight its awkward quirks by far.

kaib 15y ago

This is actually the first proper stable release since the process was introduced, the first tagged release did not go through a similar release preparation. I'm personally extremely happy with this development. We run Tinkercad on a moderately complex Go/C++ based server infrastructure (7 server types on tens of machines) and we have been lagging the Go tip given our need to avoid instability. The fact that we can now sync more often than 6 months and with less risk is great. It's a important step towards making Go a solid choice for distributed systems programming.

leon_ 15y ago

Go replaced python for me. Today morning for example I wrote a utility/demon that controls my Macbook Pros's Fan under Linux (because out of the box the fan stays @ 2000rpm till somewhere around ~80C). I've also written 2 smaller web apps using Go and I had really fun doing so. Statically typed language for webdev = <3 I can say I became a Go fanboy in the last few weeks and I hope Go gets more traction. Go @ Android would be freaking awesome.

singular 15y ago
go already targets arm, android can't be too far away.
- uriel 15y ago
  Also Brad Fitzpatrick (of LiveJournal and memcached fame) recently moved from the Android team to the Go team. Go on Android should be quite cool, but what will be awesome is Go on AppEngine.
  - singular 15y ago
    yeah I noticed him on the team. The core team has some amazing people on it, including famous people Rob Pike (Bell Labs unix/plan 9 guy) and Brad. I think that's a good sign that google are quite ambitious about the language :)
    - uriel 15y ago
      It is an amazing team, but the rest pales beside ken ('Unix guy' doesn't begin to do him justice).
      - singular 15y ago
        Don't get me wrong, I didn't mean to downplay his achievements - The guy is a legend. I'm British. I was being understated :)
  - 15y ago

timclark 15y ago

Reasons to like go: gofmt - no need to argue over coding style since it is enforced by this tool. gofix - as the language evolves, the go team provide fixes that you can run across your old source code automatically.

munificent 15y ago
If you look at the actual fixes gofix provides, most of them are to paper over a lack of language features. In particular, if Go supported function overloading, they probably wouldn't need gofix at all.
- uriel 15y ago
  Some people consider the lack of function overloading a feature. And languages that have function overloading have plenty of API changes that could benefit from something like gofix.
- supersillyus 15y ago
  I disagree. Even for the gofix fixes look to be simple "n args to n-1 args" changes, even in a language that supports function overloading I would prefer to have one version of the function, not two. The use of overloading to avoid the pain of an API change over time leads to a pretty crappy interface.
- jff 15y ago
  "If they just had function overloading, we could keep dozens of old, unmaintained functions around forever! Think how amazing documentation will be!"
  - pjscott 15y ago
    As it is, their core libraries are remarkably clean and well-designed. The source code is even a pleasure to read.
    - munificent 15y ago

Kilimanjaro 15y ago

Now all we need is Go on AppEngine. Killer.

swannodette 15y ago

What's the appeal of Go when something like OCaml exists and seems to cover much of the same territory and delivers better performance? Not trolling here, I'm genuinely curious.

uriel 15y ago
First of all, it is quite obvious that Go and OCaml are completely different languages designed around very different philosophies and styles. Also saying that you are not trolling doesn't make your comment any less trollish, specially given that your only claim is false, Go, despite still being much younger and greatly unoptimized is already considerably faster than OCaml: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=ocaml http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
- swannodette 15y ago
  I'm asking about technical merits of one over the other, which you didn't respond to at all. And look at the overall scores on the 64bit one-core and quad-core benchmarks. OCaml is ahead.
  - chc 15y ago
    I'm looking at the overall scores on the 64-bit single-core and Go is six places ahead of OCaml. On the 64-bit quad, Go is five places ahead. The only one where OCaml appears to come close is single-core 32-bit, in which Go comes out one place ahead of OCaml. (And just so we're clear: I actually like OCaml and have never used Go. So I'm not trying to wave some Go fanboy flag or anything. Those are just the numbers.)
    - swannodette 15y ago
      http://shootout.alioth.debian.org/u64q/which-language-is-best.php http://shootout.alioth.debian.org/u64q/which-language-is-bes... http://shootout.alioth.debian.org/u64/which-language-is-best.php http://shootout.alioth.debian.org/u64/which-language-is-best...

icey 15y ago

Is there any sort of "Planet" for Go? (i.e. http://planet.lisp.org/ http://planet.lisp.org/, http://planet.python.org/ http://planet.python.org/, http://www.planetscala.com/ http://www.planetscala.com/, http://planetcsharp.com/ http://planetcsharp.com/ etc?)

bockris 15y ago
http://www.gophertimes.com/ http://www.gophertimes.com/ ?
- timclark 15y ago
  Well worth reading!
uriel 15y ago
http://planet5.cat-v.org/ http://planet5.cat-v.org/ is the closest, but haven't maintained it properly for a while, I should add a few new blogs and remove some that are obsolete.
- deleted 15y ago
  [deleted]
- smosher 15y ago
  ichi ni san shi Go.