5 ms·
This is one of the things that attracts me to Go (and developing tools for working with it, which requires parsing the language, etc.). It's much easier to keep
by shurcooL 14y ago
This is one of the things that attracts me to Go (and developing tools for working with it, which requires parsing the language, etc.). It's much easier to keep the entire language spec in your working memory, because it all fits in http://golang.org/ref/spec http://golang.org/ref/spec.
- frou_dh 14y agoI agree that it's a pretty clean language, but it still has oddities. For example, where in your linked spec does it address why the following trips a compile error? func foo(b bool) { if b { return } else { return } } func bar(b bool) int { if b { return 100 } else { return 200 } } func baz(b bool) int { if b { return 100 } return 200 } func qux(b bool) int { if b { return 100 } else { return 200 } panic("?") } // Error: function [bar] ends without a return statement
- dchest 14y agohttps://code.google.com/p/go/issues/detail?id=65 https://code.google.com/p/go/issues/detail?id=65
- Dylan16807 14y agoDon't just link that with no comment. I thought you were disagreeing, not just showing that the go people have refused to fix it for two years.
- frou_dh 14y agoTo be fair, they have executed the overall project very well from what I've seen. A few things falling through the cracks is probably inevitable. That issue's not closed so there's hope for it yet.
- dchest 14y agoOK, here's the expanded text for my comment (I didn't "show something" or disagree/agree -- I just provided reference): "Here's this issue in Go bug tracker: https://code.google.com/p/go/issues/detail?id=65 https://code.google.com/p/go/issues/detail?id=65
- Dylan16807 14y agoProviding a link to the issue in the bugtracker, with discussion, is definitely "showing something". I don't know, maybe I'm just weird, but when I see a comment replied to with a single link patterns suggest that it's a link disproving something. So I got confused until I had read the full page.
- laurent123456 14y agoIs seems to be a bug but it could well be a feature. Requiring that functions end with a return statement is a good thing IMO. That avoids weird bugs if later the "else" is replaced by an "else if".
- stusmall 14y agoThat's just because its young. The same could have been said for C in the long long ago. And honestly compared to most of whats out there, C is a tiny language. Give go time, it'll bloat ;)
- shurcooL 14y agoI would hope not, as long as people like Rob Pike are around and they don't radically change their current [1] guiding principles. [1]: http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
- frou_dh 14y agoWhether generics get retrofitted will be the measure of this. I suspect they won't, because by the time a Go 2.0 timeframe arrives, the thinking will be something like "Time has shown that we thrived without them, so despite commentator gnashing, they're simply not required."
- shurcooL 14y agoIt's possible to write tools that generate code instead of building it into the language too. I wonder if it can be done better than building it into the language.
- dchest 14y agoHere's one https://github.com/droundy/gotgo https://github.com/droundy/gotgo
- frou_dh 14y agoYou could contrast achieving generics using C preprocessor gymnastics versus C++ templates.
- shurcooL 14y agoC preprocessor stuff works with text and text only. That's why it's quite hard to make things elegant. Tools can work with text and anything else you can think of. So they can potentially be better. But I don't know what could be done at this point (in fact, this might be a good problem to be analyzed from a theoretical side).
- Aardwolf 14y agoC and even C++'s spec are still easier to remember than bash shell scripting imho. For bash shell scripting, I need to keep a document full of examples to copypaste from, otherwise it's always wrong on first try anyway!