go creators why curly braces instead of significant indentation

Thought I’d read about it somewhere else too…but at least in this talk he kind of mentions the same thing “you can get burned” [?]


00:21:09,129 –> 00:21:11,989
We never considered using
white space for indentation.
I just think it’s a profound
mistake in programming language
design to have your semantics
depend on invisible characters.
There’s a reason for that.
I’ve been burned badly by bugs
introduced by invisible characters
causing changes in things.
Particularly when you combine for instance
Python through SWIG
embedded into C and C++
and various other combinations like that.

2 thoughts on “go creators why curly braces instead of significant indentation”

  1. from a comment by a go dev to the youtube:

    Go was designed to be used at scale, teams of hundreds or thousands of programmers working on massive code bases.

    You may not have had any problems using indentation for control flow, but at scale weird shit happens every day. That means that, semi-regularly, someone will sneak an invisible character into the code base that causes a subtle bug.

    This has happened more than once in Python programs at Google. The threat of control flow by indentation is real. That’s why Go uses braces.

    And my reaction

    “so basically it wants to be usable at scale” (i.e. lots of developers, same project) which…actually…might…mean that they adopted curly braces just so that more people can understand what’s going on more easily/precisely…or possibly, to not offend more people, since lots of programmers understand {}’s, but…not as many understand and well use significant indentation. They could be taught to use it, but if it wants to be used by large organizations that might require significant politics (like “large organization, just learn haskell! come one!” there’s some politics there). Just a random thought I had on it anyway…

  2. Anyone who has used make and had a bug because the backslash was followed by a whitespace knows how infuriating meaningful whitespace is. (Mine was due to translating Windows CRLF into just LF, the script turned the CR into a space, breaking every line continuation.) Add in the problem with all the many types of whitespace (space, tab, etc) and it is a potential nightmare.

    Not to mention that, for example, when adding debugging lines, I intentionally fail to indent them so I know to remove them when done. That is impossible if whitespace is meaningful, making more work for me in the name for forcing me to write pretty code.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.