3 ms·

> Here we see no parenthesizes used in if statements, yet we retain {. In skimming it's easy to miss the if in the first place. Yet everywhere else they're happ

> Here we see no parenthesizes used in if statements, yet we retain {. In skimming it's easy to miss the if in the first place. Yet everywhere else they're happy to use parenthesizes. I feel that braces on blocks are more important to readability/clarity—because blocks should be identifiable—compared to parentheses for if statements. I don't think the if gets lost in there, but if you do then that's fine. > We also see that "make" is lowercase yet a method, but os.Create and ParallelWrite has caps for a method. That's because "make" is a built-in function for building slices and maps. Packages with exportable functions (i.e. os.Create, http.HandleFunc, etc, etc) use capitalisation to denote "public" functions[1]. Functions within the os or http packages (for example) that should not be used directly by someone using the library retain a lowerCase approach. This reduces the risk and confusion surrounding which functions you should be working with when using a library. > It's also difficult to tell in the for loop if v is being assigned as "range m", or if "k, v" are a tuple resulting from "range m" Each key:value pair in m (a map, or "dictionary") is being assigned—hence the :=, which declares & assigns k & v in one line—for the entire range ('length', really). Obviously you don't agree with some of the syntax in Go. That's fine. But some of your criticisms appear to stem from a misunderstanding or lack of knowledge about some language-agnostic concepts (channels, range, exportable functions) that I don't think Go obscures. [1]: http://golang.org/doc/effective_go.html#commentary http://golang.org/doc/effective_go.html#commentary

azinman2 13y ago
I agree with you on blocks/scoping. If dropping the parens I think Python does it right with its tab-based blocks. Was uninformed about caps. That was a minor point for me, however, and in hindsight I should have at least investigated that before saying something. Ok I see the consistency in :=, but in that sense I'd personally like to see something closer to Scala where the tuple is explicit by doing something like: for (k, v) := range m { Which doesn't look all that much better, mostly because of the := (I've never liked in any lang) and the spacing between range, m, and {. for (k, v) := range(m) { Could be yet another way to help make it more clear what is modifying what. When you're tired and have been starting at code all day long having more visual gestalt in the language helps... syntax highlighting serves much of this but it's better IMHO if the language highlights itself.
- mheathr 13y ago
  Rob Pike made an excellent point in one of his presentations on GO. He pointed out that utilizing a language through a DSL or FFI that utilizes indentation instead of another method makes utilizing that language inside another language more difficult as it is easy to introduce bugs in the host language that are non-obvious to debug based on the indentation being incorrect but not obviously so. I recommend watching all of his videos as they are very illuminating due to his primary focus being that of software engineering rather than theory.

azinman2 13y ago

I agree with you on blocks/scoping. If dropping the parens I think Python does it right with its tab-based blocks. Was uninformed about caps. That was a minor point for me, however, and in hindsight I should have at least investigated that before saying something. Ok I see the consistency in :=, but in that sense I'd personally like to see something closer to Scala where the tuple is explicit by doing something like: for (k, v) := range m { Which doesn't look all that much better, mostly because of the := (I've never liked in any lang) and the spacing between range, m, and {. for (k, v) := range(m) { Could be yet another way to help make it more clear what is modifying what. When you're tired and have been starting at code all day long having more visual gestalt in the language helps... syntax highlighting serves much of this but it's better IMHO if the language highlights itself.

mheathr 13y ago
Rob Pike made an excellent point in one of his presentations on GO. He pointed out that utilizing a language through a DSL or FFI that utilizes indentation instead of another method makes utilizing that language inside another language more difficult as it is easy to introduce bugs in the host language that are non-obvious to debug based on the indentation being incorrect but not obviously so. I recommend watching all of his videos as they are very illuminating due to his primary focus being that of software engineering rather than theory.