Hacker News Reader

Comment by jgrahamc | Hacker News Reader

A very large amount of this is "Moving to a statically typed language".

1. "Different assignment operator is used depending on whether you are inside & outside of function ie. = vs :="

= is an assignment, := is a declaration and assignment at the same time. It's true that you can't := outside a function (which I think is silly), but the comparison should be between these two:

    var foo string = "Hello"
    foo := "Hello"

2. "Else (or else if) has to be formatted properly, where the else is on the same line as the curly bracket from the if clause. Weird."

Whereas, coming from Python where indentation matters. Weird :-) Both are style conventions enforced by the language.

View on HN

The same-line convention comes from automatic semicolon insertion at the end of lines. A semicolon is inserted if the line ends with "}", but not "{"... hence, "} else {". This is also the reason multi-line lists require a trailing comma.

The syntax is pretty explicit in not inserting the ';' after some characters; eg. '.' (which is why you can go:

    blah.Go().
    Go().
    Go()

Which is equivalent to:

    blah.Go().Go().Go()

I don't see why it would be significantly breaking to allow a } to similarly avoid the automatically inserted semicolon for if statements.

This wasn't a 'consequence'; this was a design decision.

> This wasn't a 'consequence'; this was a design decision.

A design decision with a sound reasoning: https://groups.google.com/forum/?fromgroups=#!topic/golang-n...

It's not the only reason. You can also just comment out some lines and it will still work just fine.

Come on, those are the two weirdest things about go syntax, especially for new comers.

(Honestly, why can you not 'for var x = 0; ...'? and only 'for var X := 0; ...; ...' but immediately below var x = 0; is just as valid. The := / var syntax in go is just plain weird).

Go is also the only place I've ever seen this syntax:

   if blah {
     ..
   } else {
     ..
   }

Maybe that's popular in some obscure places, but it is weird they made that the only valid syntax.

I mean, fair enough, Go has its own syntax, but these are pretty valid gripes.

> Go is also the only place I've ever seen this syntax:

Do you mean

    if blah {
        code
    } else {
        code
    }

as in parens-less if statement? Because I don't see anything odd in what you wrote, it's valid C or Java.

And if it's putting else, } and { on the same line, it's "standard" K&R, 1TBS, BSD KNF and java indent style/coding conventions.

I believe he's referring to the latter -- as opposed to:

    if blah {
        code
    }
    else {
        code
    }

Personally, I don't prefer the K&R way but I don't think it's either strange nor troublesome enough to worry about for more than a few seconds.

The argument is that putting anything between } and else breaks the else statement, so using } else { stresses that you cannot add statements either before or after the else.

it is weird they made that the only valid syntax

What you stated is not just that (which is not actually weird), but — quoting you

> Go is also the only place I've ever seen this syntax

compounded by

> Maybe that's popular in some obscure places

(thus calling Java's coding conventions or the K&R "obscure places")

I don't understand why this comment is being downvoted. I just learned something.

If Go enforces a specific coding convention at the compiler level, then that could legitimately be considered at least slightly unusual.

While it's true that this style is far from esoteric, it's also typically just that ( a coding style ). This strikes me as at least somewhat analogous to Python's whitespace indentation rules or Java's checked exceptions, in that what is typically a design choice is enforced by the compiler / interpreter.

It's a great choice for readability; cuts down on inconsistency.

It's because of arguments like this, that's why. They render a huge swath of subjective, unproductive discussions about style completely moot.

Well, that is the idea at least. Unfortunately it almost seems as though the style arguments will be replaced with the "pro/against enforced style" arguments.

Hopefully this new topic has less staying power.

Not, it's very pragmatic, based on a parser need (to make it simpler), and it's well explained in their docs.

Not to mention that's a well known style, has a lot of benefits (less wasted lines compared to the style that puts both brackets on empty lines, less potential for errors in than when you omit the brackets for a single statement), and, most importantly, puts and end to all bikeshedding.

Especially along with gofmt, go is a bikeshedding free language in regards to syntax.

That if/else syntax is used in K&R's The C Programming Language, the source of Unix (and thus of FreeBSD etc.), and it's pretty common in JavaScript. It may not be the most common syntax in modern C, but it's hardly weird or obscure.

> That if/else syntax is used in K&R's The C Programming Language, the source of Unix (and thus of FreeBSD etc.)

And it's part of Sun/Oracle's official java coding conventions.

Because within the scope of that for loop x has been declared.

Come on, those are the two weirdest things about go syntax, especially for new comers.

I don't really understand your 'come on'. I wasn't disagreeing with the OP about point #1, I was merely correcting what he said to make it clearer and I even agree with you (see my note about 'silly) that where you can and cannot use var and := is odd and unclear.

As for the concern about Go syntax and brace positioning, it will really depend where you come from. If have any experience of any note in any C-derived language (such as C++, Java, JavaScript, etc.) you will have seen people writing code like that for years.

> Honestly, why can you not 'for var x = 0; ...'? and only 'for var X := 0; ...; ...' but immediately below var x = 0; is just as valid. The := / var syntax in go is just plain weird

Because var and := declaration+initialization are semantically different: when declaring multiple, variables, := allows redeclaration (which just overwrites an already declared variable's value instead of shadowing it), while var does not.

> Maybe that's popular in some obscure places

Err, K&R style (from which Go's style is derived and virtually identical, except for braces of functions) isn't exactly obscure... even the Java's Coding Convention (from 1999) does it exactly like that: http://www.oracle.com/technetwork/java/javase/documentation/...

I use that conditional syntax all the time with Java.

K&R had it back in the 70s.

C was first released in 1972 and the first edition of K&R was published in 1978.

Corrected. :)

   if blah {
     ..
   } else {
     ..
   }

> Maybe that's popular in some obscure places, but it is weird they made that the only valid syntax.

That is valid K&R syntax[0], which is used prevalently in C (e.g. Linux kernel). FYI, Rob Pike wrote a few books with Brian Kernighan (the K in K&R).

Go is designed for consistency and optimized for the compiler (e.g. mandatory braces, no unused import statements). Declaring a single canonical format (e.g. gofmt / PEP 8) solves a lot of syntax bikeshedding.

[0]: https://en.wikipedia.org/wiki/Indent_style#K.26R_style

PEP-8 isn't a "canonical format" though and people should stop treating it as one.

It should be. New languages should take a hard, firm but fair, stance on style when they are first created. It is the only opportunity they will get. You can always loosen it later if you really feel the need, but you can't tighten it later on (evidenced by attitudes exactly like yours.) I mean, unless you like endless style flamewars and bickering...

Even ignoring that benefit, taking a stance on style like Go has done allows style to be handled mechanically, which is more in line with the general hacker attitude anyway. Offload that stuff to the computer; let the programmer concentrate on doing the things the computer can't.

No, it pretty much is a canonical format. You don't have to use it, but then you are out of sync with members of the Python community who wish to adhere to the standard format

>Go is also the only place I've ever seen this syntax

Then you should go read some more code. Because not only it's the one I've been using for ages (hah), but it's standard K&R style, one of the oldest and most established styles out there...

Reply on news.ycombinator.com