Rob Pike: would you consider a follow-up talk about initialization in Go: how you went about it, and why? Also, why would you want to circumvent the strict no-circular-dependency requirement? When would that be a wise choice? Great talk: love to hear the history and learn the why.
It's painfully sad that they had prejudgments towards indentation, so they poisoned the language with redundant braces. Any sane GO code will already be indented and braces are COMPLETELY redundant. Never in years of programming in Python or Coffescript I made a mistake due to indentation. Nowadays any reasonable IDE will never let you do that mistake. And putting redundant brackets everywhere annoys me greatly when I program in C, C#, Java or Javascript. You already depend on invisible characters, there is no way around it. Try to remove indentation from your code and it will become completely unreadable. People rely on indentation to read and write semantically correct code. But you can and should remove redundant brackets from your code, because it makes zero impact on semantics. People already unconsciously fully rely on "those invisible characters" (as you call it) or indentation to understand what code does. And all modern IDEs simply don't allow any indentation related mistakes to be made. Ehh... what's done is done. The damage is done. People are creatures of habits and familiarity. They will bring crooked monsters of the past, like brackets, anywhere they go, simply because they are more familiar with it. Instead of carefully examining arguments and looking at empirical evidence, they will remember a few isolated incidents from years ago when they wrote their code in some text editor instead of an IDE and use that experience to justify something that they want to do just because it's more familiar. At least they managed to shortcut "function" to "func". Small things like that are very important. You want to make language efficient to write and efficient to read. The DRY principle is not just about not redundant code. It's about being productive and thinking about how you can express the same thing in less characters, while making it more readable. "function" in javascript is one of the most used keywords and JS has very few keywords, yet it decides to use longest words for them. It's ridiculous. I understand that the goal of JS wasn't syntactical beauty, but things like good sandboxing capacities and being dynamic. But still there have to be some time spend thinking about the syntax and redundancy. Even C#, which has a lot of keywords, always tries to remove redundancy. You don't use function delegates that often, but when you do, they are called Func. Why? Because you have it's shorter to type and shorter to read. To sum it all up, it saddens me to see no further thought was put into the redundancy and beauty of syntax. Clearly choosing good short keywords was a low priority afterthought (" *P.S.* why isn't function spelled func?"). Furthermore redundant characters, like curly brackets, were introduced. At least they got rid of semicolons. That being said, I still think that many GO features and language design choices are brilliant.
I agree that braces are reduntant but it is not a popular pactise sadly, thats why they didnt want to do that. It would be a big departure for C & C++ java where are the largest pools of developers...
Braces *should be* redundant - unless, of course, someone makes a mistake. There are two ways you can deal with that - force people to use an IDE to point it out to them, or have visible semantics to show blocks (ie. braces). Not everyone wants to have to change the workflow and editor they've used for 20+ years to adopt a new language - so an IDE as a requirement would *really* have poisoned the language, because you are not going to get a die-hard vi or emacs user to use it. Big parts of the Go language design were NOT driven by making it look pretty - they're driven by real-world concerns like "can this be implemented reasonably?" and "will the Google engineers actually use it?". Braces, as an explicit sigil of semantics, make the compiler easier to write, and make the old-school hackers happy. If you don't like that - fork the language, modify it to make whitespace semantically replace braces, write that IDE, and see if your superior solution wins out over time. (if you're smart, you'll ensure object compatibility, so you can share with "traditional" Go code...)
Tom Bortels Many python guys use VIM or EMACS, so IDE is not really a requirement. An interesting fact, studies show that: _"C-style syntax, as used in Java and Perl, is just as hard for novices to learn as a randomly-designed syntax. Again, this pain is needless, because the syntax of other languages (such as Python and Ruby) is significantly easier."_ They literary created a syntax from a random generator and for novices it was on the same level as C like syntaxes. As you've said GO was designed with other things in mind, but it's still a bit funny to me. There's no use use in forking a language into dialects. Understanding a different dialect might not be that difficult. But then you be like, "I gon roll up to this git-hood and write dem patches" and on each run compiler be like, "Syntax Error: ENGLISH, m{}therf{}cker, do-you-speak-it" So it's better to just deal with it and use brackets.
Jon Wise Many python guys do use vim and emacs - and they make errors due to the whitespace. I know I do when I have to mess with something that uses syntactically-significant whitespace - not a judgement, just my history, although in my case it was a dalliance with coffeescript. Rob in his talk indicates it's not an arbitrary decision - he's had ugly issues in Python when trying to use SWIG that were caused by whitespace. I don't hear complaints about braces other than "ugly" or "not necessary because..." - so, I'd side with functionality versus aesthetics myself. Yeah - that's advanced, but see the next point: As for novices - not the target demographic for Go, and frankly given a choice, I know I prefer they aim at professionals. There are languages suited for beginners, or BASIC, which is what I learned on ("and we liked it!") I honestly don't understand the "pain" of brackets. I find them much easier to handle than whitespace, because I jump between pairs in the editor a lot, whereas with whitespace I have to eyeball it. YES - I could use an editor that folds, and yes, if my block is so long it goes off the bottom of the screen it's too damn long, but it is what it is, and with braces I can easily jump to the match (or not - and hey, I've found my bug).
***** IMO, you can't prefer one TO another, because you always use indentation to delimit code blocks. You can only prefer typing/reading extra brackets to not typing them.
he present simeple and very effective.
I respect their opinion and... move on
Here's captions (?) github.com/kickstarter/confreaks-translations/blob/master/2014-gophercon/GopherCon%202014%20Opening%20Keynote%20by%20Rob%20Pike.srt
54:37
Rob Pike: would you consider a follow-up talk about initialization in Go: how you went about it, and why? Also, why would you want to circumvent the strict no-circular-dependency requirement? When would that be a wise choice? Great talk: love to hear the history and learn the why.
It's painfully sad that they had prejudgments towards indentation, so they poisoned the language with redundant braces. Any sane GO code will already be indented and braces are COMPLETELY redundant. Never in years of programming in Python or Coffescript I made a mistake due to indentation. Nowadays any reasonable IDE will never let you do that mistake. And putting redundant brackets everywhere annoys me greatly when I program in C, C#, Java or Javascript. You already depend on invisible characters, there is no way around it. Try to remove indentation from your code and it will become completely unreadable. People rely on indentation to read and write semantically correct code. But you can and should remove redundant brackets from your code, because it makes zero impact on semantics. People already unconsciously fully rely on "those invisible characters" (as you call it) or indentation to understand what code does. And all modern IDEs simply don't allow any indentation related mistakes to be made. Ehh... what's done is done. The damage is done. People are creatures of habits and familiarity. They will bring crooked monsters of the past, like brackets, anywhere they go, simply because they are more familiar with it. Instead of carefully examining arguments and looking at empirical evidence, they will remember a few isolated incidents from years ago when they wrote their code in some text editor instead of an IDE and use that experience to justify something that they want to do just because it's more familiar. At least they managed to shortcut "function" to "func". Small things like that are very important. You want to make language efficient to write and efficient to read. The DRY principle is not just about not redundant code. It's about being productive and thinking about how you can express the same thing in less characters, while making it more readable. "function" in javascript is one of the most used keywords and JS has very few keywords, yet it decides to use longest words for them. It's ridiculous. I understand that the goal of JS wasn't syntactical beauty, but things like good sandboxing capacities and being dynamic. But still there have to be some time spend thinking about the syntax and redundancy. Even C#, which has a lot of keywords, always tries to remove redundancy. You don't use function delegates that often, but when you do, they are called Func. Why? Because you have it's shorter to type and shorter to read.
To sum it all up, it saddens me to see no further thought was put into the redundancy and beauty of syntax. Clearly choosing good short keywords was a low priority afterthought (" *P.S.* why isn't function spelled func?"). Furthermore redundant characters, like curly brackets, were introduced. At least they got rid of semicolons.
That being said, I still think that many GO features and language design choices are brilliant.
I agree that braces are reduntant but it is not a popular pactise sadly, thats why they didnt want to do that. It would be a big departure for C & C++ java where are the largest pools of developers...
Braces *should be* redundant - unless, of course, someone makes a mistake. There are two ways you can deal with that - force people to use an IDE to point it out to them, or have visible semantics to show blocks (ie. braces). Not everyone wants to have to change the workflow and editor they've used for 20+ years to adopt a new language - so an IDE as a requirement would *really* have poisoned the language, because you are not going to get a die-hard vi or emacs user to use it. Big parts of the Go language design were NOT driven by making it look pretty - they're driven by real-world concerns like "can this be implemented reasonably?" and "will the Google engineers actually use it?". Braces, as an explicit sigil of semantics, make the compiler easier to write, and make the old-school hackers happy. If you don't like that - fork the language, modify it to make whitespace semantically replace braces, write that IDE, and see if your superior solution wins out over time. (if you're smart, you'll ensure object compatibility, so you can share with "traditional" Go code...)
Tom Bortels
Many python guys use VIM or EMACS, so IDE is not really a requirement. An interesting fact, studies show that:
_"C-style syntax, as used in Java and Perl, is just as hard for novices to learn as a randomly-designed syntax. Again, this pain is needless, because the syntax of other languages (such as Python and Ruby) is significantly easier."_
They literary created a syntax from a random generator and for novices it was on the same level as C like syntaxes. As you've said GO was designed with other things in mind, but it's still a bit funny to me.
There's no use use in forking a language into dialects. Understanding a different dialect might not be that difficult. But then you be like, "I gon roll up to this git-hood and write dem patches" and on each run compiler be like, "Syntax Error: ENGLISH, m{}therf{}cker, do-you-speak-it" So it's better to just deal with it and use brackets.
Jon Wise Many python guys do use vim and emacs - and they make errors due to the whitespace. I know I do when I have to mess with something that uses syntactically-significant whitespace - not a judgement, just my history, although in my case it was a dalliance with coffeescript. Rob in his talk indicates it's not an arbitrary decision - he's had ugly issues in Python when trying to use SWIG that were caused by whitespace. I don't hear complaints about braces other than "ugly" or "not necessary because..." - so, I'd side with functionality versus aesthetics myself. Yeah - that's advanced, but see the next point:
As for novices - not the target demographic for Go, and frankly given a choice, I know I prefer they aim at professionals. There are languages suited for beginners, or BASIC, which is what I learned on ("and we liked it!")
I honestly don't understand the "pain" of brackets. I find them much easier to handle than whitespace, because I jump between pairs in the editor a lot, whereas with whitespace I have to eyeball it. YES - I could use an editor that folds, and yes, if my block is so long it goes off the bottom of the screen it's too damn long, but it is what it is, and with braces I can easily jump to the match (or not - and hey, I've found my bug).
*****
IMO, you can't prefer one TO another, because you always use indentation to delimit code blocks. You can only prefer typing/reading extra brackets to not typing them.