4 ms·

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 -

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
densh 15y ago
You can't imagine how annoying is it in python world to use libraries which always provide inconsistent naming scheme. You'll easily find camelCase, snake_case, nocapitalorunderscorecase in any large project. Even though pep8 exists, neither standard library nor most of 3rd party developers conform to it. Go's CapitalEverythingNaming convention is quite annoying but the mere fact that it'll be used everywhere makes me happy.
drivebyacct2 15y ago
>Forcing one brace style This has been discussed numerous times on the mailing list. The answer, for good reasons, is too bad. As you note in your conclusion, consistency is prioritized above configuration. There's reasons for this, they were meticulously debated and chose by the designers to help people out. If you have a pure Go project, you can install it anywhere Go is available in a single command. No autotools, no makefiles, no build-essentials, nothing. Just a single `go get` command. If you ever work on a decent sized project in Go, you will quickly come to appreciate the enforced consistency across the project. >To use the Go tool you are required to have your directories set up in a specific way Not with the binary distribution. And "have a source directory on GoPath" is too restrictive... set `GOPATH=~` and for 90%+ of users, their existing dir structure is perfectly fine. >No support for using user defined types as map keys This is no longer true IIRC. >Two initialization functions, new and make. One returns a pointer, the other a struct. I don't understand why this is a negative?
- MatthewPhillips 15y ago
  I've been off Go for a while, weren't they thinking about getting rid of new at some point? I recall a long thread on the mailing list debating dropping it.
  - drivebyacct2 15y ago
    Most of the "debates" I've seen have been people desperately trying to explain that they do different things under the hood and thus removing the different keywords adds 'magic' that they don't want.
dchest 15y ago
Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. You can use any indentation depth in Go too. But in Python you can't get rid of indentation because its lexer expects it, just like you can't get rid of the "forced" brace style in Go, because its lexer expects it.

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

densh 15y ago

You can't imagine how annoying is it in python world to use libraries which always provide inconsistent naming scheme. You'll easily find camelCase, snake_case, nocapitalorunderscorecase in any large project. Even though pep8 exists, neither standard library nor most of 3rd party developers conform to it. Go's CapitalEverythingNaming convention is quite annoying but the mere fact that it'll be used everywhere makes me happy.

drivebyacct2 15y ago

>Forcing one brace style This has been discussed numerous times on the mailing list. The answer, for good reasons, is too bad. As you note in your conclusion, consistency is prioritized above configuration. There's reasons for this, they were meticulously debated and chose by the designers to help people out. If you have a pure Go project, you can install it anywhere Go is available in a single command. No autotools, no makefiles, no build-essentials, nothing. Just a single `go get` command. If you ever work on a decent sized project in Go, you will quickly come to appreciate the enforced consistency across the project. >To use the Go tool you are required to have your directories set up in a specific way Not with the binary distribution. And "have a source directory on GoPath" is too restrictive... set `GOPATH=~` and for 90%+ of users, their existing dir structure is perfectly fine. >No support for using user defined types as map keys This is no longer true IIRC. >Two initialization functions, new and make. One returns a pointer, the other a struct. I don't understand why this is a negative?

MatthewPhillips 15y ago
I've been off Go for a while, weren't they thinking about getting rid of new at some point? I recall a long thread on the mailing list debating dropping it.
- drivebyacct2 15y ago
  Most of the "debates" I've seen have been people desperately trying to explain that they do different things under the hood and thus removing the different keywords adds 'magic' that they don't want.

dchest 15y ago

Even python which catches flak for forcing indentation as tabs let's you choose the indentation depth and character. You can use any indentation depth in Go too. But in Python you can't get rid of indentation because its lexer expects it, just like you can't get rid of the "forced" brace style in Go, because its lexer expects it.