GopherCon 2014 Videos

This is a point that folks new to Go often miss. I oftentimes see people compare "interface{}" to "Object" in Java, which is not true.

(If you don't believe me, note that not everything in Java is actually an Object - since there are multiple typekinds[0], that means that not every type can be used where Java expects to see an Object). That is part of the reason for the mess surrounding the so-called wrapper types like Integer (which are themselves neither objects (wrappers are passed by value, not reference) nor primitives (they are in most[1] cases unboxed to primitives, but are not themselves the same things as primitives).

Aside from the fact that Java didn't add generics until 1.5 (if I remember correctly), which certainly didn't stop its popularity, it cannot be emphasized enough that the need for generics is dramatically reduced if one actually understands how to use interfaces idiomatically in Go and understands how they are different from "interfaces" in Java or other languages[2].

While I occasionally run into a situation in which Java-like generics would make things marginally easier, they're few and far between; interfaces bridge far more of the difference than non-Go programmers often realize. And has has been explained to death already (both at Gophercon and on the mailing list) - generics are not out of the question for a hypothetical Go 2, but there are going to be no more changes to the language syntax for Go 1.

[0] I counted either 5 or 6 at one point when I was using Java heavily in university, but that was several years ago so don't quote me on that exact number.

[1] emphasis on "most" - there are some very "fun" edge cases that you can find here!

[2] I'm reminded of how Haskell has both "class" and "return" as keywords that have nothing to do with their Java counterparts - I think Go's "interface" is along the same lines - it's the same identifier/term, but a very different meaning.

> However, we don't read text vertically, we read it horizontally (I know there are exceptions, but not in any significant programming languages that I know of).

I think we do read code vertically and it is significant in all programming languages, and I think that it is a core problem with acceptance of Lisps, because they unusually strongly avoid leveraging the two-dimensional nature of typical code editing environments in favor of having pretty much the perfect purely-horizontal syntax.

> So I would say that while both cases have the problem that we can only observe whitespace by the characters that surround them, in the vertical whitespace that happens at a coarser, less ambiguous level than horizontal whitespace.

I do think there is an ambiguity difference, but its not because we read horizontally but not vertically, but because horizontal whitespace in common use -- i.e., that people are used to using on a keyboard in the context of programming -- is limited to newlines (and, while there are different means of expressing newlines, they are mostly driven by platform rather than personal preference and are, in any case, easy to account for), whereas tab/space holy wars are as old as line oriented PLs that allow indentation (whether they are sensitive to it or not).

It's true: not all features yield net benefit.

> I think we do read code vertically and it is significant in all programming languages

Of course it is significant, I was agreeing with you there! But my point was:

d

o

_

y

o

u

_

e

v

e

r

_

w

r

i

t

e

_

c

o

d

e

_

l

i

k

e

_

t

h

i

s

?

But maybe I should have worded it differently: we read text in "row-major order", not "column-major order". That's basically the difference I talk about.

Also, there is another difference between newlines and indentation: newlines only go "forward" (next line), whereas with indentation you go back and forth into levels of indentation. It's not the same. The closest thing I can think of is that one language where you could write the exponent of a formula on a line before, faking superscript, or the index of a formula on the next, faking subscript. Making mono-typed source code look like math formulas basically (and probably a pain to type out). That's the only programming context I can think of where newlines are actually significant in a similar fashion to indentation.

This seems like a logical fallacy. Of course you have to separate your language's tokens with something. This is not "significant" whitespace. It's token delimiters, and they don't generally need whitespace. for example func(){return 1} has no whitespace between func and the open paren, also

    func        (){     
            a := 1
                          return a

             }

while ugly, this still compiles just fine. It would compile just as fine if you randomly flipped some of the spaces into tabs.

Whitespace is not significant in Go.

The difference between significant whitespace and requiring "some" whitespace is that if you did something like that in Python, you could end up with a program with different logic depending on which spaces were flipped to tabs. This is why mixing spaces and tabs in Python is verboten.

In go, you can mix spaces and tabs all you want, wherever you want in your code and it will never ever change the logic of your code, period. (obvious exceptions for changes inside string literals)

So, it's not really a matter of degrees, and Python's method is completely broken if you ever mix tabs and spaces, which as Rob Pike points out, are completely indistinguishable in the default views of most editors.