Hacker News new | comments | show | ask | jobs | submit login

I thought I knew C.



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.


I 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



Don'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.


To 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.


OK, 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


Providing 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.


Is 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".


C 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!


That'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 ;)


Not only because it's young, also because we _do_ learn from mistakes made in other languages.

For example, I do not see PL/I's choice to make none of its keywords reserved names (IIRC, defended on the argument that one cannot expect anybody to know all the reserved words) repeated much anymore in Algol-like languages.

As another example, IDE/language pairs such as Eclipse/Java have learned us the advantages of languages that are easy to parse and where there is little ambiguity even in incomplete or incorrect programs (it makes syntax coloring easier, and allows for refactoring tools that are somewhat reliable on non conforming source code)


I 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-exponen...


Whether 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."


It'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.



You could contrast achieving generics using C preprocessor gymnastics versus C++ templates.


C 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).


What makes me wary of using these uncommon constructs is that someone editing code later may make a change based on a superficial understanding (and break the build)


Much less likely than someone editing code later using his superficial understanding of C++ :)


After the fifth time dealing with subordinates misunderstanding template constructs I decided to throw out all of the C++ code and reimplement in "simple" C and x64 assembly -- at least now people don't mess with the assembly


Or Ruby. Or C. Or Scala. Or Haskell. Or JavaScript. Or Go.

You get the point I hope.


It's not that easy, I'm afraid. Languages do differ in many areas and one of them is how easy it is to make a mistake in one.

I think Go was designed with this in mind? Also, Haskell's type system guards against this. On the other hand C does nothing to prevent you from shooting yourself in the foot and C++, while improving some things, makes it overall worse because of sheer amount of constructs in the language.

Ruby and JS are better in that they run on VMs and so won't segfault (that often), but other than that they do very little to help avoid making mistakes (implicit undefineds passed to functions in JS...).

Anyway, languages are not created equal and one thing a language designer can optimize for is to reduce the probability of programmer making mistake. That's only one of the variables however and sometimes it's the other goals that are more important and then we get languages like C++. That's not to say it's bad, it's just optimized for different things.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: