9 ms·

Go 1 Release Candidate 1

84 points by jbarham 15y ago

jeffffff 15y ago
releasing without generics is a huge mistake
- cageface 15y ago
  Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can complicate a language implementation considerably.
  - ootachi 15y ago
    From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
  - densh 15y ago
    Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
    - kristianp 15y ago
      Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.
- p9idf 15y ago
  Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics: http://research.swtch.com/generic http://research.swtch.com/generic http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go. † Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.
  - ootachi 15y ago
    As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way to write generic code, programmers will end up paying the exact same taxes via their handwritten non-generic code. Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
    - eternalban 15y ago
      Let's take case (a) -- that's the approach I adopted when implementing a Splay tree, introducing a Comparator interface. Granted it is a bit of a pain to write IntComparator, LongComparator, etc., but given that Go is not an object oriented language e.g. all types do not support a (hypothetical) CompareTo(other T), it is not clear to me how would the availability of generics would help in this case. For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
- jbarham 15y ago
  I've written a fair bit of Go code, and rarely miss generics. Two Go features in particular help to mitigate the lack of generics: 1. The built-in array/slice and map containers are effectively generic since they can act as containers for any type. 2. Interfaces (http://weekly.golang.org/ref/spec#Interface_types http://weekly.golang.org/ref/spec#Interface_types) define a set of common methods that can be implemented by multiple concrete types. See e.g. the ubiquitous io.Reader interface (http://weekly.golang.org/pkg/io/#Reader http://weekly.golang.org/pkg/io/#Reader), and the SQL database driver package (http://weekly.golang.org/pkg/database/sql/driver/ http://weekly.golang.org/pkg/database/sql/driver/) that defines a collection of interfaces that define an interface to any SQL database. FWIW I've written a concrete PostgreSQL driver: https://github.com/jbarham/gopgsqldriver https://github.com/jbarham/gopgsqldriver.
- enneff 15y ago
  On the contrary, it is vitally important. Go 1 was a stabilization of what we already had, not an occasion to introduce new features. If Go gets generics it will have a profound effect on the language and its libraries. better to introduce them in Go 2 once we know what they are and have a wealth of experience with them.
  - soc88 15y ago
    Does this make _any_ sense? Normally you introduce stuff having "profund effect"s on the whole ecosystem _before_ you release something as "stable". Maybe the Go devs want to repeat the Java generics story ...
    - enneff 15y ago
      Sure, we could have introduced generics (we have a pretty decent proposal in the works) and then tweaked it for another couple of years, but that wouldn't be fair to the thousands of Go programmers (including those at Google) who need to use Go in their day-to-day lives. As has been mentioned elsewhere, part of the problem with Java's generics story was that they needed to maintain backward compatibility at all costs. The same won't be true for Go 2, which may include support for generics. Go 1 is a solid product - language, standard library, and tools - and one we will support for years to come. There will be a time for experimenting with generics but that time isn't now. Why is everyone in such a rush?
- MatthewPhillips 15y ago
  We already have Java.
  - batista 15y ago
    And that is relevant because? Generics aren't a unique trait of Java --quite the opposite: the language existed for a decade without them, and even now doesn't have a nice implementation of them.
    - MatthewPhillips 15y ago
      > And that is relevant because? The goal of C-like languages isn't to duplicate Java features. Go (and others) have their own set of goals. In this case generics doesn't advance the goals.
      - batista 15y ago
        Actually, the goals doesn't have anything to do with the presence of generic in the language or not. Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.
btipling 15y ago
The language is pretty much amazing. There is so much that is right with it. The tools are very helpful. The makefile free build tool it ships with, 'go', is great. Things are really well documented. The source code is easy to read. I have been working on making a control panel with Go for our APIs. It has been pretty straight forward and painless to pick up on go.
- yorhel 15y ago
  Actually, the 'go' tool is one of the things I rather dislike in Go so far. It's good to have to tool that does everything for you, but I'd like to at least be able to structure my directories in the way I want. For mixed-language projects you won't get rid of Makefiles either way, and they're really not that bad with the right include files or Makefile generation tools. Using URLs to identify external libraries also isn't something I'm very fond of. Both because you'd have more boilerplate to type when using them, and suddenly the library is fixed to a certain internet location and VCS. Meh, I can go on ranting about other things I dislike about Go, but it wouldn't solve anything. I'll just keep monitoring the developments from the sideline and see how things evolve over time.
  - 4ad 15y ago
    The URLs are not really fixed, there's a feature which I am not sure if it's documented yet that allows for an indirection between a shorter import path and the real import path, so you could change the VCS or the real location.
jbarham 15y ago
One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re-built the current RC release on my 2.67 GHz i5, and the whole build, including the C bootstrap environment and 300k+ LOC in the standard library, took under 30 seconds. Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.
- chimeracoder 15y ago
  >how phenomenally fast the compiler is This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.
- rudiger 15y ago
  A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.
  - 4ad 15y ago
    Yes, the projects at Google in C++ or Java took an absurd amount of time to compile, even with distributed compiler farms.
- deleted 15y ago
  [deleted]
- deleted 15y ago
  [deleted]
- knotty66 15y ago
  I think the D compiler (dmd) is faster still. Granted, this is a couple of years old, but DMD was capable of compiling 340,000 lines of code in less than 7 seconds. http://www.digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html http://www.digitalmars.com/d/archives/digitalmars/D/D_compil...
BarkMore 15y ago
According to various sources on the Interwebs, Go sucks for one or more of the following reasons: - No generics. - No exceptions. - No inheritance. - Nullable pointers. - No decimal types (yet they put in complex!) - No IDE. - No support for GUI applications on Microsoft Windows. - Go ignores years of academic research on language design. Please ignore the people who are happily productive with the language :).
- lclarkmichalek 15y ago
  Funny, none of those reasons are why I now avoid go. For me what killed it was: - Forcing one brace style - Forcing naming conventions to a certain extent - To use the Go tool you are required to have your directories set up in a specific way - All types are not equal: No support for using user defined types as map keys, maps are generic, but user defined types are not - Two initialization functions, new and make. One returns a pointer, the other a struct. Seeing as go makes no distinction between the stack and the heap, is there need for two. Convention over configuration is great and all, but it really felt as if it was being used as an excuse to force me to use someone else's style. Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. Go made me feel slightly violated; forcing my directory layout was the last straw, and the lack of any configuration in a place where it would not be complex to add it seamed stupid.
  - canop_fr 15y ago
    A few comments : - I find that having a common style about source files from different origins (we're in the open source era) and common naming conventions are great for the readability. I can decipher foreign code much easier if I don't have to set my mind about the bracing style. And seriously, would you prefer to have "private" and "public" all in the place instead of this simple convention ? - I found it a little painful too, at first, to have to mix source and binary in my projects with the advent of the go tool but the removal of redundant makefiles and its simplicity of use, especially when you deal with a lot of projects and packages from diverse origins is so great that it's hard to protest against that. - Are you sure you're up to date about map keys ? http://tip.golang.org/ref/spec#Map_types http://tip.golang.org/ref/spec#Map_types
kristianp 15y ago
It's also been pushed to App Engine: http://groups.google.com/group/golang-nuts/browse_thread/thread/9434eea15a05af8d http://groups.google.com/group/golang-nuts/browse_thread/thr...
drivebyacct2 15y ago
If this thread proves anything, it's that independent research is needed when picking a language. There are many inaccuracies, anecdotes and personal opinions that in my and many others' opinions don't matter once you've actually built something useful in Go.
- grourk 15y ago
  "There are many inaccuracies, anecdotes and personal opinions that in my and many others' opinions don't matter..." The content of your comment renders your comment meaningless. It's like a Hofstadter Strange Loop of meaninglessness.
  - drivebyacct2 15y ago
    I anticipated this comment, though I decided against discussing it. The core concept is clearly: "It's that independent research is needed when picking a language." and my anecdote merely served to counter the negativity and reiterate the importance of evaluating language choice based on one's needs.
melling 15y ago
Wouldn't Go be a good fit for Android? That would be on my wish list.

84 points by jbarham 15y ago

jeffffff 15y ago

releasing without generics is a huge mistake

cageface 15y ago
Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can complicate a language implementation considerably.
- ootachi 15y ago
  From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
- densh 15y ago
  Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
  - kristianp 15y ago
    Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.
p9idf 15y ago
Your argument is not clear to me. However allow me to share some of the Go authors' thoughts about generics: http://research.swtch.com/generic http://research.swtch.com/generic http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... I am inclined to agree with them. I like writing Go programs quickly, but not at the expense of compilation speed† or execution speed. The point of Go is to be fast. If I valued programming speed for a particular program, then I would use the right tool for the job and choose a language other than Go. † Though considering the speed of Plan 9-style compilers, I can't imagine at what scale this would begin to be a problem.
- ootachi 15y ago
  As I stated below, Go's lack of generics isn't buying the language anything from an implementation standpoint. What Russ Cox is missing is that, absent some way to write generic code, programmers will end up paying the exact same taxes via their handwritten non-generic code. Consider, for example, a binary search tree that can be instantiated with keys of int type or keys of string type. There are two ways to implement this in Go: (a) use an interface and dispatch calls through a vtable; or (b) implement the tree twice, once for ints and once for strings. But note: these two implementation strategies carry the exact same costs as the corresponding implementation strategies for generics! In the case of (a), the programmer is performing boxing via interface types, while in the case of (b), the programmer is performing code duplication. So not having generics doesn't relieve Go programs of compile-time or runtime overhead in any way; it simply increases the burden on the programmer.
  - eternalban 15y ago
    Let's take case (a) -- that's the approach I adopted when implementing a Splay tree, introducing a Comparator interface. Granted it is a bit of a pain to write IntComparator, LongComparator, etc., but given that Go is not an object oriented language e.g. all types do not support a (hypothetical) CompareTo(other T), it is not clear to me how would the availability of generics would help in this case. For basic type coercion, yes, it is a pita to write boxing code, and clearly a maintenance issue as well.
jbarham 15y ago
I've written a fair bit of Go code, and rarely miss generics. Two Go features in particular help to mitigate the lack of generics: 1. The built-in array/slice and map containers are effectively generic since they can act as containers for any type. 2. Interfaces (http://weekly.golang.org/ref/spec#Interface_types http://weekly.golang.org/ref/spec#Interface_types) define a set of common methods that can be implemented by multiple concrete types. See e.g. the ubiquitous io.Reader interface (http://weekly.golang.org/pkg/io/#Reader http://weekly.golang.org/pkg/io/#Reader), and the SQL database driver package (http://weekly.golang.org/pkg/database/sql/driver/ http://weekly.golang.org/pkg/database/sql/driver/) that defines a collection of interfaces that define an interface to any SQL database. FWIW I've written a concrete PostgreSQL driver: https://github.com/jbarham/gopgsqldriver https://github.com/jbarham/gopgsqldriver.
enneff 15y ago
On the contrary, it is vitally important. Go 1 was a stabilization of what we already had, not an occasion to introduce new features. If Go gets generics it will have a profound effect on the language and its libraries. better to introduce them in Go 2 once we know what they are and have a wealth of experience with them.
- soc88 15y ago
  Does this make _any_ sense? Normally you introduce stuff having "profund effect"s on the whole ecosystem _before_ you release something as "stable". Maybe the Go devs want to repeat the Java generics story ...
  - enneff 15y ago
    Sure, we could have introduced generics (we have a pretty decent proposal in the works) and then tweaked it for another couple of years, but that wouldn't be fair to the thousands of Go programmers (including those at Google) who need to use Go in their day-to-day lives. As has been mentioned elsewhere, part of the problem with Java's generics story was that they needed to maintain backward compatibility at all costs. The same won't be true for Go 2, which may include support for generics. Go 1 is a solid product - language, standard library, and tools - and one we will support for years to come. There will be a time for experimenting with generics but that time isn't now. Why is everyone in such a rush?
MatthewPhillips 15y ago
We already have Java.
- batista 15y ago
  And that is relevant because? Generics aren't a unique trait of Java --quite the opposite: the language existed for a decade without them, and even now doesn't have a nice implementation of them.
  - MatthewPhillips 15y ago
    > And that is relevant because? The goal of C-like languages isn't to duplicate Java features. Go (and others) have their own set of goals. In this case generics doesn't advance the goals.
    - batista 15y ago
      Actually, the goals doesn't have anything to do with the presence of generic in the language or not. Plus, the creators of Go have stated that Generics are indeed considered strongly as an addition to the language post 1.0.

btipling 15y ago

The language is pretty much amazing. There is so much that is right with it. The tools are very helpful. The makefile free build tool it ships with, 'go', is great. Things are really well documented. The source code is easy to read. I have been working on making a control panel with Go for our APIs. It has been pretty straight forward and painless to pick up on go.

yorhel 15y ago
Actually, the 'go' tool is one of the things I rather dislike in Go so far. It's good to have to tool that does everything for you, but I'd like to at least be able to structure my directories in the way I want. For mixed-language projects you won't get rid of Makefiles either way, and they're really not that bad with the right include files or Makefile generation tools. Using URLs to identify external libraries also isn't something I'm very fond of. Both because you'd have more boilerplate to type when using them, and suddenly the library is fixed to a certain internet location and VCS. Meh, I can go on ranting about other things I dislike about Go, but it wouldn't solve anything. I'll just keep monitoring the developments from the sideline and see how things evolve over time.
- 4ad 15y ago
  The URLs are not really fixed, there's a feature which I am not sure if it's documented yet that allows for an indirection between a shorter import path and the real import path, so you could change the VCS or the real location.

jbarham 15y ago

One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re-built the current RC release on my 2.67 GHz i5, and the whole build, including the C bootstrap environment and 300k+ LOC in the standard library, took under 30 seconds. Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.

chimeracoder 15y ago
>how phenomenally fast the compiler is This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.
rudiger 15y ago
A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.
- 4ad 15y ago
  Yes, the projects at Google in C++ or Java took an absurd amount of time to compile, even with distributed compiler farms.
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
knotty66 15y ago
I think the D compiler (dmd) is faster still. Granted, this is a couple of years old, but DMD was capable of compiling 340,000 lines of code in less than 7 seconds. http://www.digitalmars.com/d/archives/digitalmars/D/D_compilation_speed_vs._go_108831.html http://www.digitalmars.com/d/archives/digitalmars/D/D_compil...

BarkMore 15y ago

According to various sources on the Interwebs, Go sucks for one or more of the following reasons: - No generics. - No exceptions. - No inheritance. - Nullable pointers. - No decimal types (yet they put in complex!) - No IDE. - No support for GUI applications on Microsoft Windows. - Go ignores years of academic research on language design. Please ignore the people who are happily productive with the language :).

lclarkmichalek 15y ago
Funny, none of those reasons are why I now avoid go. For me what killed it was: - Forcing one brace style - Forcing naming conventions to a certain extent - To use the Go tool you are required to have your directories set up in a specific way - All types are not equal: No support for using user defined types as map keys, maps are generic, but user defined types are not - Two initialization functions, new and make. One returns a pointer, the other a struct. Seeing as go makes no distinction between the stack and the heap, is there need for two. Convention over configuration is great and all, but it really felt as if it was being used as an excuse to force me to use someone else's style. Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. Go made me feel slightly violated; forcing my directory layout was the last straw, and the lack of any configuration in a place where it would not be complex to add it seamed stupid.
- canop_fr 15y ago
  A few comments : - I find that having a common style about source files from different origins (we're in the open source era) and common naming conventions are great for the readability. I can decipher foreign code much easier if I don't have to set my mind about the bracing style. And seriously, would you prefer to have "private" and "public" all in the place instead of this simple convention ? - I found it a little painful too, at first, to have to mix source and binary in my projects with the advent of the go tool but the removal of redundant makefiles and its simplicity of use, especially when you deal with a lot of projects and packages from diverse origins is so great that it's hard to protest against that. - Are you sure you're up to date about map keys ? http://tip.golang.org/ref/spec#Map_types http://tip.golang.org/ref/spec#Map_types

kristianp 15y ago

It's also been pushed to App Engine: http://groups.google.com/group/golang-nuts/browse_thread/thread/9434eea15a05af8d http://groups.google.com/group/golang-nuts/browse_thread/thr...

drivebyacct2 15y ago

If this thread proves anything, it's that independent research is needed when picking a language. There are many inaccuracies, anecdotes and personal opinions that in my and many others' opinions don't matter once you've actually built something useful in Go.

grourk 15y ago
"There are many inaccuracies, anecdotes and personal opinions that in my and many others' opinions don't matter..." The content of your comment renders your comment meaningless. It's like a Hofstadter Strange Loop of meaninglessness.
- drivebyacct2 15y ago
  I anticipated this comment, though I decided against discussing it. The core concept is clearly: "It's that independent research is needed when picking a language." and my anecdote merely served to counter the negativity and reiterate the importance of evaluating language choice based on one's needs.

melling 15y ago

Wouldn't Go be a good fit for Android? That would be on my wish list.