5 ms·

> Lack of docs, broken and confusing functionality, limited language features, bizarre operations. You are painting with a pretty broad brush, can you provide

> Lack of docs, broken and confusing functionality, limited language features, bizarre operations. You are painting with a pretty broad brush, can you provide a concrete example of these?

dartharva 4y ago
I don't know how applicable this is, but even the basic if-else syntax can hit you with hours of frustrating struggles. The parantheses have to be arranged in a specific way that was never mentioned in the online language specs over at go.dev, otherwise the code will fail: if (cond) { return x } else { return y } works, but if (cond) { return x } else { return y } doesn't.
- Queue29 4y ago
  > never mentioned in the online language specs over at go.dev hmm, what's this then? https://go.dev/doc/faq#Does_Go_have_a_ternary_form https://go.dev/doc/faq#Does_Go_have_a_ternary_form
  - dartharva 4y ago
    That's the FAQ. The official Language Specification says nothing about this little gimmick, at least in the if-else section: https://go.dev/ref/spec#If_statements https://go.dev/ref/spec#If_statements You'd think one would want to look for it in that instead of an FAQ page.
    - enneff 4y ago
      If you looked at the spec which provides simple, valid examples that work, then why would you spend hours writing different code wondering why it doesn’t work? The section you linked does explain it, btw. IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] . Note there is no newline or semicolon between Block and the optional “else” clause, and a Block is thusly defined: Block = "{" StatementList "}" . So that being the case I’m not sure why you’d assume it’s valid to put a newline after the trailing “}” of the Block, before the “else”. The other factor at play here is the treatment of semicolons: https://go.dev/ref/spec#Semicolons https://go.dev/ref/spec#Semicolons All of this is quite natural once you use the language. in fact, it was designed this way in response to the way it was being used. It is not appropriate for the spec to constantly reiterate concepts that have already been introduced, but rather it should precisely define each concept once. If you want to learn a language from its spec then it behooves you to consider the document as a whole. That requires a lot of mental overhead and I think most people are better off learning from examples and tutorials rather than reading a language spec.
      - AnimalMuppet 4y ago
        To someone coming from C, C++, or Java, the idea that a newline would change the meaning is completely novel. And Go has the same "flavor" as those languages, so most people would expect Go to behave the same unless the difference were called out very explicitly.
        enneff 4y ago
        I think the absence of semicolons is a pretty big call-out.
- Beltalowda 4y ago
  The reason it doesn't work is because of how semicolons work: like in C every statement needs to end in a semicolon, but the compiler will automatically insert them if the last word in a line is a keyword (continue etc.), an identifier, literal value (int, string, etc.), or ++, --, ), ], }. [1] So your example gets transformed to: if (cond) { return x }; else { return y }; So it is mentioned in the language specification, just as a non-obvious consequence of this. It's not my most favourite part of the language either, but at least the compiler message on it is better now (it used to complain about semicolons, which was confusing because they're not there in your source code; now it just says "unexpected else, expecting }", which is still a bit confusing but better). I'm fairly sure The Go Programming Language book mentions this somewhere near the beginning, but some of the online tutorial/tour perhaps could be improved. There's always a bit of a balance in how much to mention. [1]: https://go.dev/ref/spec#Semicolons https://go.dev/ref/spec#Semicolons
- cschep 4y ago
  I think gofmt will fix this for you?

> Lack of docs, broken and confusing functionality, limited language features, bizarre operations. You are painting with a pretty broad brush, can you provide a concrete example of these?

dartharva 4y ago

I don't know how applicable this is, but even the basic if-else syntax can hit you with hours of frustrating struggles. The parantheses have to be arranged in a specific way that was never mentioned in the online language specs over at go.dev, otherwise the code will fail: if (cond) { return x } else { return y } works, but if (cond) { return x } else { return y } doesn't.

Queue29 4y ago
> never mentioned in the online language specs over at go.dev hmm, what's this then? https://go.dev/doc/faq#Does_Go_have_a_ternary_form https://go.dev/doc/faq#Does_Go_have_a_ternary_form
- dartharva 4y ago
  That's the FAQ. The official Language Specification says nothing about this little gimmick, at least in the if-else section: https://go.dev/ref/spec#If_statements https://go.dev/ref/spec#If_statements You'd think one would want to look for it in that instead of an FAQ page.
  - enneff 4y ago
    If you looked at the spec which provides simple, valid examples that work, then why would you spend hours writing different code wondering why it doesn’t work? The section you linked does explain it, btw. IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] . Note there is no newline or semicolon between Block and the optional “else” clause, and a Block is thusly defined: Block = "{" StatementList "}" . So that being the case I’m not sure why you’d assume it’s valid to put a newline after the trailing “}” of the Block, before the “else”. The other factor at play here is the treatment of semicolons: https://go.dev/ref/spec#Semicolons https://go.dev/ref/spec#Semicolons All of this is quite natural once you use the language. in fact, it was designed this way in response to the way it was being used. It is not appropriate for the spec to constantly reiterate concepts that have already been introduced, but rather it should precisely define each concept once. If you want to learn a language from its spec then it behooves you to consider the document as a whole. That requires a lot of mental overhead and I think most people are better off learning from examples and tutorials rather than reading a language spec.
    - AnimalMuppet 4y ago
      To someone coming from C, C++, or Java, the idea that a newline would change the meaning is completely novel. And Go has the same "flavor" as those languages, so most people would expect Go to behave the same unless the difference were called out very explicitly.
      - enneff 4y ago
        I think the absence of semicolons is a pretty big call-out.
Beltalowda 4y ago
The reason it doesn't work is because of how semicolons work: like in C every statement needs to end in a semicolon, but the compiler will automatically insert them if the last word in a line is a keyword (continue etc.), an identifier, literal value (int, string, etc.), or ++, --, ), ], }. [1] So your example gets transformed to: if (cond) { return x }; else { return y }; So it is mentioned in the language specification, just as a non-obvious consequence of this. It's not my most favourite part of the language either, but at least the compiler message on it is better now (it used to complain about semicolons, which was confusing because they're not there in your source code; now it just says "unexpected else, expecting }", which is still a bit confusing but better). I'm fairly sure The Go Programming Language book mentions this somewhere near the beginning, but some of the online tutorial/tour perhaps could be improved. There's always a bit of a balance in how much to mention. [1]: https://go.dev/ref/spec#Semicolons https://go.dev/ref/spec#Semicolons
cschep 4y ago
I think gofmt will fix this for you?