4 ms·

"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether y

"For me, Go's major shortcoming is its community's lack of focus on readability as compared to Python." Can you be a bit more concrete here? Because whether you like the code styles enforced by gofmt and the compiler itself or not, Go is the most consistently readable language I've ever used (once you adapt yourself to the language). IMO, this seems like an especially odd problem for someone to have with Go.

ak217 14y ago
Idiomatic Go: http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things) When comparing the two, I'm not impressed with Go.
- winter_blue 14y ago
  The first link, Effective Go doesn't talk about the philosophy behind idiomatic Go, like _Code like a Pythonista_ does. There is however snippets of Go code on that page, and it's fairly reminiscent of C/C++. I don't really see that as a drawback, for I believe C code is fairly readable for what it offers (speed.) Go likeness to C doesn't offend me one bit, considering the power and speed it offers versus C.
- lambda 14y ago
  What makes you unimpressed? Why do you think that Python clearly wins? Do you think that the additional type safety, namespace safety, and ease of concurrency in Go are worth nothing? Or do you just think that Python has more that outweigh that? I know that I frequently kick myself in Python when I typo a name somewhere, and everything dies far beyond where I made the mistake because it goes along happily storing something into that typoed variable, and then when I read it later it has the wrong value, and it takes me a while to trace back and find where I made the typo.
  - paul-woolcock 14y ago
    This is what linting tools like pyflakes are for. Running it as a prerequisite to running the test suite means that I don't have to run all my tests just to find out that I misspelled a variable name.
epidemian 14y ago
I can't speak for @ak217, but for me Go hits a bad spot on "expressibility". Some of the nuances of static typing are mitigated a bit with features, yes, like the type inference on local variables, or the automatic interface detection (i.e. no explicit "type X implements Y"). But overall, i think the chosen type system is lacking on expressibility. Having no parametric polymorphism in a static language is a deal breaker for me at least. No way of doing type-safe parametric container types for example.
- strmpnk 14y ago
  It's a fair complaint. Duplicating code just for the sake of type specialization is annoying and interface{} has it's costs as well as dangers. However, the built-in arrays, slices, and maps (which are parametrically polymorphic) seem to have covered all the cases where I need parametric types so far. Maybe I'm just lucky or haven't written enough lines of Go but it seems like an 80/20 sort of feature in the presence of the built-in maps.
- Evbn 14y ago
  You can use reflection to get parametricity. Python doesn't have type safe anything, so Go bests Python on that front.
  - rryan 14y ago
    If I'm going to be burdened by a static type system, then I expect it to do certain things for me in return. One of those things that I take as a given is that a static type system can check that my basic use of types in my program are safe. Not being able to type-check something as simple as a container lookup is a show-stopper for me because using containers is a huge part of day-to-day programming. Static typing without parametric polymorphism is extremely retrograde -- like Java in the 90's. I've read rsc's essays on adding parametric polymorphism to Go -- I'm not saying it's a "duh -- just add parametric polymorphism". I'm well aware of the issues -- I'm just saying that Go looks great except for this glaring exception.
wonderzombie 14y ago
Agreed. I think we, as a profession, have a tendency to focus on what's "easy" (syntax and constructs we're already familiar with) to the exclusion of other, potentially more important factors. I am and have been guilty of this myself, so I'm not claiming any sort of sainthood, just making an observation. Often people pick on the use of single-letter variable names as "unreadable." This is mostly a matter of keeping the code light on the page, as they put it. If you're dealing with a package centered around Foo, especially methods on same, it's customary to just abbreviate it to f. That clashes with a lot of people's instincts even though, once you get used to it, it works well. "Once you get used to it" is key -- this is true of any language with substantially new or different syntax/semantics from what a programmer is used to. All else being equal, familiarity ought to be orthogonal to merit; the mere presence of a learning curve ought not be a deal-breaker. Anyway, Go is one of the most readable languages I've ever seen, given that it is not a scripting language. Among other things, type inference and literals make the code very clean, to the point where you can in short order read the standard library code and expect to understand it.
- dantotheman 14y ago
  I think the issue with single-letter variables goes deeper than it just being unreadable (although its that too for someone that isn't "used to it"). For example there are issues with scope (what happens when I need a second or third "f" variable" and maintainability too (6 months from now I have to remember if "f" stands for "foo" or "file").
  - Evbn 14y ago
    You can look at the method signature that accepts or returns f. At worst case, you need an IDE with hover popups, or to open the functions doc page or source code.
  - shasta 14y ago
    Speaking of scope issues, you're missing a paren.
  - lambda 14y ago

ak217 14y ago

Idiomatic Go: http://golang.org/doc/effective_go.html http://golang.org/doc/effective_go.html Idiomatic Python: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html http://python.net/~goodger/projects/pycon/2007/idiomatic/han... (doesn't cover a number of important things) When comparing the two, I'm not impressed with Go.

winter_blue 14y ago
The first link, Effective Go doesn't talk about the philosophy behind idiomatic Go, like _Code like a Pythonista_ does. There is however snippets of Go code on that page, and it's fairly reminiscent of C/C++. I don't really see that as a drawback, for I believe C code is fairly readable for what it offers (speed.) Go likeness to C doesn't offend me one bit, considering the power and speed it offers versus C.
lambda 14y ago
What makes you unimpressed? Why do you think that Python clearly wins? Do you think that the additional type safety, namespace safety, and ease of concurrency in Go are worth nothing? Or do you just think that Python has more that outweigh that? I know that I frequently kick myself in Python when I typo a name somewhere, and everything dies far beyond where I made the mistake because it goes along happily storing something into that typoed variable, and then when I read it later it has the wrong value, and it takes me a while to trace back and find where I made the typo.
- paul-woolcock 14y ago
  This is what linting tools like pyflakes are for. Running it as a prerequisite to running the test suite means that I don't have to run all my tests just to find out that I misspelled a variable name.

epidemian 14y ago

I can't speak for @ak217, but for me Go hits a bad spot on "expressibility". Some of the nuances of static typing are mitigated a bit with features, yes, like the type inference on local variables, or the automatic interface detection (i.e. no explicit "type X implements Y"). But overall, i think the chosen type system is lacking on expressibility. Having no parametric polymorphism in a static language is a deal breaker for me at least. No way of doing type-safe parametric container types for example.

strmpnk 14y ago
It's a fair complaint. Duplicating code just for the sake of type specialization is annoying and interface{} has it's costs as well as dangers. However, the built-in arrays, slices, and maps (which are parametrically polymorphic) seem to have covered all the cases where I need parametric types so far. Maybe I'm just lucky or haven't written enough lines of Go but it seems like an 80/20 sort of feature in the presence of the built-in maps.
Evbn 14y ago
You can use reflection to get parametricity. Python doesn't have type safe anything, so Go bests Python on that front.
- rryan 14y ago
  If I'm going to be burdened by a static type system, then I expect it to do certain things for me in return. One of those things that I take as a given is that a static type system can check that my basic use of types in my program are safe. Not being able to type-check something as simple as a container lookup is a show-stopper for me because using containers is a huge part of day-to-day programming. Static typing without parametric polymorphism is extremely retrograde -- like Java in the 90's. I've read rsc's essays on adding parametric polymorphism to Go -- I'm not saying it's a "duh -- just add parametric polymorphism". I'm well aware of the issues -- I'm just saying that Go looks great except for this glaring exception.

wonderzombie 14y ago

Agreed. I think we, as a profession, have a tendency to focus on what's "easy" (syntax and constructs we're already familiar with) to the exclusion of other, potentially more important factors. I am and have been guilty of this myself, so I'm not claiming any sort of sainthood, just making an observation. Often people pick on the use of single-letter variable names as "unreadable." This is mostly a matter of keeping the code light on the page, as they put it. If you're dealing with a package centered around Foo, especially methods on same, it's customary to just abbreviate it to f. That clashes with a lot of people's instincts even though, once you get used to it, it works well. "Once you get used to it" is key -- this is true of any language with substantially new or different syntax/semantics from what a programmer is used to. All else being equal, familiarity ought to be orthogonal to merit; the mere presence of a learning curve ought not be a deal-breaker. Anyway, Go is one of the most readable languages I've ever seen, given that it is not a scripting language. Among other things, type inference and literals make the code very clean, to the point where you can in short order read the standard library code and expect to understand it.

dantotheman 14y ago
I think the issue with single-letter variables goes deeper than it just being unreadable (although its that too for someone that isn't "used to it"). For example there are issues with scope (what happens when I need a second or third "f" variable" and maintainability too (6 months from now I have to remember if "f" stands for "foo" or "file").
- Evbn 14y ago
  You can look at the method signature that accepts or returns f. At worst case, you need an IDE with hover popups, or to open the functions doc page or source code.
- shasta 14y ago
  Speaking of scope issues, you're missing a paren.
- lambda 14y ago