6 ms·

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 t

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
      It's pretty to make version one of your language's libraries clean and simple. The real challenge is how they hold up over time and the needs of evolution. Go's philosophy seems to be: 1. Simplicity matters more than compatibility. 2. Assume all extant Go code is easily mutable. The purist in me finds that appealing, but I'm not sure how that will hold up over the long term. The language seems intentionally designed to not evolve which doesn't seem like a good way to stay useful for real people for a long time. Maybe I'm wrong and everything will work out, but I wonder if several years from now, Go will just fall over from its inflexibility and become unusable.
      - uriel 15y ago
        > The language seems intentionally designed to not evolve This is a strange claim to make given how much the language (and its libraries) have actually evolved during their little more than a year of life.
      - jff 15y ago
        You typically can't even compile Linux with the previous GCC version, yet somehow that kernel has been tottering along for about 20 years now. If you compile a program using Go, you get a binary that will run forever. Statically linked, contains the runtime, you're all set. If you update Go, you can then re-build that same program, but you might have to update a few things to get a working binary again--but you only have to do this if, somehow, that originally-compiled binary isn't working for you. If Python decides they want to change the syntax for opening a file, then you can either 1. Keep a second Python around forever for compatibility or 2. Modify your program so it uses the new syntax. Go will never do this to you; as long as your OS continues to support the same binary format, I don't see why a binary shouldn't work indefinitely.
    - timclark 15y ago
      Reading the source code is also an excellent way to learn Go!
- singular 15y ago
  Am with the siblings - disagree very much. A very nice thing about go is that it isn't afraid to say 'no' to features, nor is it afraid to enforce conventions to encourage consistency. I bet the coding standard discipline at google has something to do with it, as described by Steve Yegge[1]:- "Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places." [1]:http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
singular 15y ago
Other reasons to like go:- Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand. Extremely fast compiles - you miss this when you go back to languages that compile more slowly. It allows for rapid prototyping and trying stuff out without having to worry about a massive build time. Check out this vid - [1]. Great concurrency support - concurrency is primitive in go via go-routines. Sensible, simple, clean syntax. The list goes on... yeah I need to do a blog post here :) [1]:http://www.youtube.com/watch?v=wwoWei-GAPo http://www.youtube.com/watch?v=wwoWei-GAPo
- BrandonM 15y ago
  > Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand. I think you're referring to duck typing, which Python has leveraged heavily for over a decade (http://en.wikipedia.org/wiki/Duck_typing#History http://en.wikipedia.org/wiki/Duck_typing#History).
  - robfig 15y ago
    I'm not sure if what Go is doing is "Duck Typing", but there's a huge difference from Python. In Go, something implements an Interface by virtue of having the right method. No "implements" declaration is necessary. This is statically typed and safe at compile time, while Python is not. Does anyone know what this feature/pattern is called? As far as I know, Go is the first language to have this feature. Seems different from "Duck Typing" to me.. Reference: http://golang.org/doc/go_faq.html#types http://golang.org/doc/go_faq.html#types Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.
stewbrew 15y ago
I personally find go an interesting language I'd like to learn but why should the apparent need for something like gofix make you like the language.
- zerosanity 15y ago
  While the Go language is still under development you will run into problems from syntax and API changes. I think the existence of the gofix command speaks more about the quality of the effort put into Go as a whole. They actually put in the effort to make syntax and API changes as easy to fix as possible.
- __david__ 15y ago
  The alternative is the way C++ was handled--for a very long time new stuff would be added to compilers in a non-backwards way and break all your code. This was happening pretty much every time you got a compiler update and was very frustrating. "gofix" seems like a pretty good compromise for using the language while it's developing and not having your code break constantly.

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
    It's pretty to make version one of your language's libraries clean and simple. The real challenge is how they hold up over time and the needs of evolution. Go's philosophy seems to be: 1. Simplicity matters more than compatibility. 2. Assume all extant Go code is easily mutable. The purist in me finds that appealing, but I'm not sure how that will hold up over the long term. The language seems intentionally designed to not evolve which doesn't seem like a good way to stay useful for real people for a long time. Maybe I'm wrong and everything will work out, but I wonder if several years from now, Go will just fall over from its inflexibility and become unusable.
    - uriel 15y ago
      > The language seems intentionally designed to not evolve This is a strange claim to make given how much the language (and its libraries) have actually evolved during their little more than a year of life.
    - jff 15y ago
      You typically can't even compile Linux with the previous GCC version, yet somehow that kernel has been tottering along for about 20 years now. If you compile a program using Go, you get a binary that will run forever. Statically linked, contains the runtime, you're all set. If you update Go, you can then re-build that same program, but you might have to update a few things to get a working binary again--but you only have to do this if, somehow, that originally-compiled binary isn't working for you. If Python decides they want to change the syntax for opening a file, then you can either 1. Keep a second Python around forever for compatibility or 2. Modify your program so it uses the new syntax. Go will never do this to you; as long as your OS continues to support the same binary format, I don't see why a binary shouldn't work indefinitely.
  - timclark 15y ago
    Reading the source code is also an excellent way to learn Go!
singular 15y ago
Am with the siblings - disagree very much. A very nice thing about go is that it isn't afraid to say 'no' to features, nor is it afraid to enforce conventions to encourage consistency. I bet the coding standard discipline at google has something to do with it, as described by Steve Yegge[1]:- "Google is an exceptionally disciplined company, from a software-engineering perspective. They take things like unit testing, design documents and code reviews more seriously than any other company I've even heard about. They work hard to keep their house in order at all times, and there are strict rules and guidelines in place that prevent engineers and teams from doing things their own way. The result: the whole code base looks the same, so switching teams and sharing code are both far easier than they are at other places." [1]:http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...

singular 15y ago

Other reasons to like go:- Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand. Extremely fast compiles - you miss this when you go back to languages that compile more slowly. It allows for rapid prototyping and trying stuff out without having to worry about a massive build time. Check out this vid - [1]. Great concurrency support - concurrency is primitive in go via go-routines. Sensible, simple, clean syntax. The list goes on... yeah I need to do a blog post here :) [1]:http://www.youtube.com/watch?v=wwoWei-GAPo http://www.youtube.com/watch?v=wwoWei-GAPo

BrandonM 15y ago
> Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand. I think you're referring to duck typing, which Python has leveraged heavily for over a decade (http://en.wikipedia.org/wiki/Duck_typing#History http://en.wikipedia.org/wiki/Duck_typing#History).
- robfig 15y ago
  I'm not sure if what Go is doing is "Duck Typing", but there's a huge difference from Python. In Go, something implements an Interface by virtue of having the right method. No "implements" declaration is necessary. This is statically typed and safe at compile time, while Python is not. Does anyone know what this feature/pattern is called? As far as I know, Go is the first language to have this feature. Seems different from "Duck Typing" to me.. Reference: http://golang.org/doc/go_faq.html#types http://golang.org/doc/go_faq.html#types Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

stewbrew 15y ago

I personally find go an interesting language I'd like to learn but why should the apparent need for something like gofix make you like the language.

zerosanity 15y ago
While the Go language is still under development you will run into problems from syntax and API changes. I think the existence of the gofix command speaks more about the quality of the effort put into Go as a whole. They actually put in the effort to make syntax and API changes as easy to fix as possible.
__david__ 15y ago
The alternative is the way C++ was handled--for a very long time new stuff would be added to compilers in a non-backwards way and break all your code. This was happening pretty much every time you got a compiler update and was very frustrating. "gofix" seems like a pretty good compromise for using the language while it's developing and not having your code break constantly.