7 ms·

Go has a way of programming. Go is totally optimized for that way of programming, in fact. Programming any way other than Go’s way, with Go, will be that recipe

• dsl 14y ago
  From what I was able to gather, the authors gripes tend to be with the lack of meaningful whitespace and "tabs". Both the goto arguments of someone who lacks enough understanding of language fundamentals to point out any actual flaws.
  • mischov 14y ago
    For the sake of accuracy there was also some stuff in there about a conflict between first-class functions and the type system, and some stuff about errors being easy-to-ignore return values.
    • charlieflowers 14y ago
      Yes, and those are pretty solid points. Too substantial to just sweep under the rug.
    • charlieflowers 14y ago
      Yes, and those are pretty solid points. Too substantial to just sweep under the rug.
    • deleted 14y ago
      [deleted]
  • StavrosK 14y ago
    I'm a die-hard Python/PEP8 fan. Non-significant whitespace, I could take or leave, but tabs as indentation just make sense. You're separating form from content, which, as programmers, we should be all for. As a pedant and an anal retentive person, I love gofmt. It's a big part of my coding peace of mind.
    • eblume 14y ago
      As I describe language structure in Go to people, I keep telling them that "go fmt" is an amazing tool that you will wish you had for every language. I am met with many incredulous stares at the suggestion that a program that messes with your formatting could be a good thing... but it is!
  • pretoriusB 14y ago
    >From what I was able to gather, the authors gripes tend to be with the lack of meaningful whitespace and "tabs". Then you weren't able to gather enough. Besides tons of other stuff he mentions in the post, he has a comment below it adding: - The existence of make() for the "our language is not powerful enough for us to express our language" tops the list for me. A couple more off the top of my head: - Stack allocation is quietly converted to heap allocation iff a pointer to the stack allocated object escapes. - Maps, channels, and slices are non-pointer reference "special" types. - Struct literals require a dangling a comma, but you cannot use dangling commas elsewhere. - make(), new(), and import() all look like function invocations, but are also syntax(ish) (and have special support in the parser). In the case of the first two, they even return values. >Both the goto arguments of someone who lacks enough understanding of language fundamentals to point out any actual flaws. Well, then again, the above looks like the goto response of someone that didn't really got the article (which show a great understanding of Go, even if we forget the added clarifications in the comment section).
• azth 14y ago
  The `make` function is an example of an inconcistency. The language does not have generics, yet this built-in function is a generic one. As far as Go being safer and cleaner because it lacks modern language features, generics would make the language safer (compare to casting all over the place, which is less safe, and has a runtime cost). Some modern languages also don't have null pointers, further increasing safety.
  • chimeracoder 14y ago
    Generics aren't included for two reasons: 1. They haven't figured out a way to implement them without impacting performance significantly 2. They're not as necessary as you might think. While they're open to adding them if #1 changes, in response to #2, I find I don't miss them as much as I would have thought - and that's coming from a strong advocate of statically typed, functional languages. In idiomatic Go, I just don't need them as often as I would have thought, and the interfaces are well-designed enough to make up for much of the difference. http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature_X http://golang.org/doc/go_faq.html#Why_doesnt_Go_have_feature...
    • azth 14y ago
      I have read those same arguments over and over. Just because generics do not come up as often does not mean they won't make programs safer and/or faster. Almost all of the workarounds I have seen for the lack of generics can easily be applied to Java for instance. There were several questions that came up on the Go mailing list asking how to convert certain code to make it more "idiomatic". The resulting code had several layers of indirection, interfaces composed of interfaces, and so on, that ironically it would have looked much more concise, and would have been type safe in a more "traditional OO" language like Java.
      • jlgreco 14y ago
        Not sure why you would expect to hear anything but the same thing over and over, in response to the same complaint being raise.. over and over. I don't think anyone denies that adding generics, if done properly, would improve the language. The only real controversial thing being suggested is that generics are not worth an implementation that is not up to standards. Personally, I think that is a reasonable position.
• shadowmint 14y ago
  var i = 0; <--- valid i := 0 <--- Valid for (i := 0; ...) <--- Valid for (var i = 0; ...) <--- Invalid No?
  • jgrahamc 14y ago
    I'm not sure how much you know about Go based on your comment, but you have a ; in the first line that is not legal in Go (and you haven't declared the type); you have parens on your for loop and that too is not valid. If I rewrite your comment in correct Go I get var i int = 0 // valid i := 0 // valid for i := 0; ... { // valid for var i int = 0; ... { // Not valid Your final line there is only needed if you want to define the type of i at declaration time inside a for loop. That would be better written for i := int(0); ... {
    • shadowmint 14y ago
      Sure; I was just saying, the parent comment asked for an example of inconsistency there it is. Either allow the use of var to declare a variable, or dont. Dont mix and match in different contexts; this clearly violates the go goal of consistent syntax. Edit, incidentally the use of var is perfectly legal like this: package main import "fmt" func main() { var a = 10 b := 10 fmt.Printf("%d %d\n", a, b); for i := 0; i < 10; i++ { fmt.Printf("%d Value\n", i) } }
    • swdunlop 14y ago
      Actually, the following is valid syntax in Go 1.0 and later: var i = 0 The use of "var" without a type is a common idiom when binding global variables, such as: var ErrTooLarge = errors.New("bytes.Buffer: too large") Oddly, the := shortcut is not legal in the global context. Also fun: var ( i = 0 j = 0 ) So, going back to the original comment -- yes, Go has some odd little shortcuts and inconsistencies.
      • StavrosK 14y ago
        Why is := not valid in the global context? I have been bitten by this time and time again. Is there a reason for it? It makes no sense to me.
• robfig 14y ago
  My least favorite feature is block scoping combined with the := operator. For example, this works: var x Foo x, err := doSomething() if err != nil { ... } this does not: var x Foo if x, err := doSomething(); err != nil { ... } This pattern (or some variant) introduces more bugs in my code than I would like to admit.
  • jgrahamc 14y ago
    What do you mean by 'does not work'? Your second example will work but the x declared in the if statement will be local to that statement (note not to the block but the entire statement). In both cases you have redeclared x. In the second the scope is different. See: http://play.golang.org/p/c9B-FXL0Fw http://play.golang.org/p/c9B-FXL0Fw