Hacker News Reader

Comment by smithcoin | Hacker News Reader

> 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?

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.

> 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

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

You'd think one would want to look for it in that instead of an FAQ page.

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

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.

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.

I think the absence of semicolons is a pretty big call-out.

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

I think gofmt will fix this for you?

Reply on news.ycombinator.com