5 ms·

The comments thread on this makes me sort of sad. So... Go rocks because a) you've got to handle all the errors b) there is no method_missing (or its ilk) I

by th0br0 13y ago

The comments thread on this makes me sort of sad. So... Go rocks because a) you've got to handle all the errors b) there is no method_missing (or its ilk) In general, all those features have been offered by compiled languages for years (even if they might've just been compiler warnings). What makes Go so special other than the lack of deep class hierarchies? Sure, it's more "reliable" by design than 100% of those dynamic languages out there, but that doesn't really make the language more attractive. Coming from an OO world, I find Go's "inheritance" model far inferior to what, e.g., Haskell or Scala offer. Given the comments here I think that I can finally understand somewhat why Go is taking off the way it is, but it feels like a faulty "solution".

khyryk 13y ago
a isn't necessarily the case. Consider fmt.Println: func Println(a ...interface{}) (n int, err error) I've never seen any code that handled err -- I don't mean ignoring it with _, I mean not even acknowledging its existence -- without the compiler saying anything.
- dilap 13y ago
  Yeah, but if print fails, what are you going to do? And it's not like ignoring this error is going to make your code blow up.
  - khyryk 13y ago
    The point is that I can't immediately tell which errors will be mysteriously ignored. This, together with the existence of panics, undermines the stance that one can tell exactly what a certain piece of Go code will do just by looking at, say, a function prototype.
    - cmccabe 13y ago
      Don't be fatuous. If you wrote all of the code, you should be able to tell exactly what it does. If there's some code you're calling that was written by someone else, you have to trust it to do the right thing. Exceptions versus return codes doesn't change that fact. People usually don't check the return code of fmt.Printf because they simply don't care. Most of the time, you're just logging to a terminal, which basically never fails. And if logging did fail, you wouldn't want to abort the program because of it. The only time you might want to check the return value of printf is if you're writing a simple utility designed to transform something passed on stdin to something on stdout.
      - khyryk 13y ago
        How am I being fatuous? It is obviously false that there is any sort of guarantee that errors have to be dealt with if the compiler allows some indeterminate number of functions (unless there's a list somewhere) to be exceptions to the rule.
  - apw 13y ago
    If your program is expected to operate in a pipeline, as most UNIX programs are, shouldn't you always check for printf returning an error? For example: yourprogram | head -100
    - dilap 13y ago
      I'm not sure, actually, what's the proper way to do it? For fun, I wrote three programs that just print 1 2 3 ... to stdout forever, in python, go, and plain c. None do any error checking. Here's the results: $ py printcount.py | head -10 1 2 3 4 5 6 7 8 9 10 Traceback (most recent call last): File "printcount.py", line 3, in <module> print i IOError: [Errno 32] Broken pipe $ go run printcount.go | head -10 1 2 3 4 5 6 7 8 9 10 signal: broken pipe $ ./printcount | head -10 1 2 3 4 5 6 7 8 9 10 $ pgrep printcount $ Interestingly enough, only plain old C actually did what I wanted here. In Go and Python, we'd have to do a little work to not print the annoying error. But I don't think we want to check return codes from print in any of the languages.
mitchellh 13y ago
Both the original post and comments such as mine have made no mention comparing Go to other languages. We're just saying that Go itself is reliable. Not that others aren't or that Go is more reliable than others.
thrownaway2424 13y ago
I think most people who are pleased with the reliability of Go are coming from something like Python where unforeseen things pop up out of nowhere on rare code paths nobody anticipated. Things like a rare error handling path where some piece of code iterates over a string the author thought was a list, etc. Or perhaps they are coming from C++ where use-after-free or use-of-uninitialized or use-of-perversely-initialized are common at runtime. Go has none of that.
- jbooth 13y ago
  Or java/c# where exceptions tend to bubble all the way up the stack and where you have to to try/finally which can be harder to write safe code with than defer.
  - danieldk 13y ago
    Or java/c# where exceptions tend to bubble all the way up the stack There is really no difference. In Java you have to decide at what level to catch exceptions. In Go you have to decide at what level to handle an error and just not return it. In fact, if you have to pass an error on level further up the stack, it's easier in Java. have to to try/finally which can be harder to write safe code with than defer. Why? I suppose that you are referring to the fact that you can put a defer right next to e.g. opening a file. But Java has the (arguably) nice(r) try-with-resources construct since Java 7: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html http://docs.oracle.com/javase/tutorial/essential/exceptions/...
    - jbooth 13y ago
      I'm not a Java hater, I love it, but a lot of code tends to be written as just "throws IOException". I've written a lot of code like that. Go forces you to handle each error separately, which can be nice.
  - pjmlp 13y ago
    defer is no different than using(C#), try-resources(Java), scope(D), with(Python).
corresation 13y ago
The comments thread on this makes me sort of sad. The comments are almost ancillary, but if I'm reading the original correctly it is saying that Go itself -- the compiler, the garbage collection, and the "standard library", is incredibly reliable. Which has been my impression as well -- after years with a number of other languages and platforms, my first impulse when hitting an unexpected issue is looking into the platform/compiler/etc, to discover those edge conditions that I need to navigate around. Go, however...when something doesn't work as I expected, at this point I have an extremely high confidence that it is something I've done wrong. That is really unexpected in such a young ecosystem.
steveklabnik 13y ago
The Go love makes a lot of sense when you consider it's out to replace Python and Ruby, and not other statically typed compiled languages. If you learned programming via Python, and then moved to Go, it would seem revelatory. If you've previously done a lot of statically typed work, it's much more meh.
- kaib 13y ago
  I'll counter your anecdotal evidence with my anecdotal evidence. I know a few systems guys who have three or more decades of experience with statically typed languages who prefer Go. :-)
  - steveklabnik 13y ago
    I didn't say you shouldn't prefer it, just that it's not as big a deal.
- burntsushi 13y ago
  Not for me. I had previously done Haskell work, and I find Go to be awesome. And I still think Haskell is awesome. Weird, eh?
  - steveklabnik 13y ago
    I didn't even say 'bad,' I said 'more meh.' Furthermore, I didn't say that liking go makes you hate other languages, or that you should hate go if you like other languages...
    - burntsushi 13y ago
      > I didn't even say 'bad,' I said 'more meh.' I didn't say "bad" either.................. I said "awesome", which is in stark contrast to "more meh"................ > Furthermore, I didn't say that liking go makes you hate other languages, or that you should hate go if you like other languages... I didn't say you did. My implication was that people don't have to fit your mold of the world: I enjoy programming in many different kinds of languages. i.e., I liked Go at the outset even though I had previously done significant work in a static typed language with a rich type system.
aaronblohowiak 13y ago
The explanation of why I like Go is best found in: "Less is exponentially more": http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
- nostrademons 13y ago
  Somewhat ironically, that is exactly the same philosophy that was embodied in Java when it came out, and Java has grown so that it's now mentioned in the same breath as C++ when compared to Go. I think what happens in all languages - indeed, in all engineering projects - is that people start using them, and then their design collides with the real world, and people start asking for new features to make their own lives better, and each additional feature makes the language incrementally better without costing much. But when this has been going on for 20 years, you have an accretion of features that don't quite hang together and collectively are a royal pain to deal with. Eventually enough folks get fed up with this state that a new language can gain critical mass, and the cycle starts over again. The only languages immune to this are ones that explicitly reject certain use-cases as out-of-scope, and can design accordingly. C, for example, remains a great little language because it doesn't pretend to shield you from the dangers of the hardware, and so it can remain both fast and simple because everyone who wants it to scale up to big complicated applications reaches for C++ or Java instead. Python remains great as long as you remember that it's a scripting language and don't pretend that it'll be fast or maintainable beyond a certain size.
  - danieldk 13y ago
    But when this has been going on for 20 years, you have an accretion of features that don't quite hang together and collectively are a royal pain to deal with. Eventually enough folks get fed up with this state that a new language can gain critical mass, and the cycle starts over again. I agree, but Java the language hasn't become much more complicated. In fact, it's development has been quite glacial, one of the reasons that some JVM-minded people switch to Scala. Probably the larger problem is that Java (to the Python/Ruby and now Go crowd) became associated with applets and big and ugly frameworks that require heaps of XML. However, Java the language doesn't differ all that much from Go. Java is better in some respects (generics, checked exceptions) and Go is nicer in some respects (closures). However, Java has an insanely great runtime (JVM) that can be fully instrumented, supports hot code swapping (some natively, DCEVM, JRebel). It also has a zillion great libraries, good IDEs, great web frameworks (that don't require writing XML), etc. Go will be popular in start ups, etc. Some people will take it into big corps (as happened with Python and Ruby). But to be used widely in the industry, it needs everything and more than the JVM or .NET offer.
bsdetector 13y ago
> Given the comments here I think that I can finally understand somewhat why Go is taking off the way it is The comments here are incredibly biased in Go's favor, for whatever reason. On other forums it does not get the same spotlight, for instance it has been mostly dismissed on reddit and is rarely even discussed there at all (even on it's own subreddit).
cmccabe 13y ago
It seems like you missed a lot of the other things he said, such as "testing is built into the language," and "binaries are statically compiled and will work on any reasonable kernel." These may not be sexy features, but they are features that you need to actually make reliable programs. And frankly, yes, Go's approach to handling errors is a Big Deal. It's counter to the tendency of the last few years to move more and more error handling into exceptions. In retrospect, we can see that that was a mistake, similar to the "natural language programming" dead-end that led to COBOL and HyperCard. Challenging the exception-handling orthodoxy is absolutely something interesting and new. What makes Go so special other than the lack of deep class hierarchies? This is an "other than that, Mrs. Lincoln, how was the play?" type of comment. Go's type system is absolutely huge in terms of making it special. It would never have attracted the attention it did if it were just another Modula-3 rehash like Java, C++, D, etc.
- masklinn 13y ago
  > And frankly, yes, Go's approach to handling errors is a Big Deal. It's not. > It's counter to the tendency of the last few years to move more and more error handling into exceptions. Haskell says hi. Go's error handling is a step back not because it tries to avoid exceptions but because it's a crummy very slight improvement over C error handling. Contrary to what you believe, the world has moved on since then, even outside of exceptions-based error handling. > Challenging the exception-handling orthodoxy is absolutely something interesting and new. It absolutely is not new, and there is nothing interesting to the way Go did it (which is a significant downgrade of Erlang's way of handling errors) > Go's type system is absolutely huge in terms of making it special. You have not answered the question. > It would never have attracted the attention it did Of course it would, the attention it attracted is due to its backers, not to its intrinsic qualities (of which it has few, lost in a morass of decisions which would have been bad 30 years ago).
pjmlp 13y ago
> What makes Go so special other than the lack of deep class hierarchies? Google sponsored language with HN rockstars in their team.

by th0br0 13y ago

khyryk 13y ago

a isn't necessarily the case. Consider fmt.Println: func Println(a ...interface{}) (n int, err error) I've never seen any code that handled err -- I don't mean ignoring it with _, I mean not even acknowledging its existence -- without the compiler saying anything.

dilap 13y ago
Yeah, but if print fails, what are you going to do? And it's not like ignoring this error is going to make your code blow up.
- khyryk 13y ago
  The point is that I can't immediately tell which errors will be mysteriously ignored. This, together with the existence of panics, undermines the stance that one can tell exactly what a certain piece of Go code will do just by looking at, say, a function prototype.
  - cmccabe 13y ago
    Don't be fatuous. If you wrote all of the code, you should be able to tell exactly what it does. If there's some code you're calling that was written by someone else, you have to trust it to do the right thing. Exceptions versus return codes doesn't change that fact. People usually don't check the return code of fmt.Printf because they simply don't care. Most of the time, you're just logging to a terminal, which basically never fails. And if logging did fail, you wouldn't want to abort the program because of it. The only time you might want to check the return value of printf is if you're writing a simple utility designed to transform something passed on stdin to something on stdout.
    - khyryk 13y ago
      How am I being fatuous? It is obviously false that there is any sort of guarantee that errors have to be dealt with if the compiler allows some indeterminate number of functions (unless there's a list somewhere) to be exceptions to the rule.
- apw 13y ago
  If your program is expected to operate in a pipeline, as most UNIX programs are, shouldn't you always check for printf returning an error? For example: yourprogram | head -100
  - dilap 13y ago
    I'm not sure, actually, what's the proper way to do it? For fun, I wrote three programs that just print 1 2 3 ... to stdout forever, in python, go, and plain c. None do any error checking. Here's the results: $ py printcount.py | head -10 1 2 3 4 5 6 7 8 9 10 Traceback (most recent call last): File "printcount.py", line 3, in <module> print i IOError: [Errno 32] Broken pipe $ go run printcount.go | head -10 1 2 3 4 5 6 7 8 9 10 signal: broken pipe $ ./printcount | head -10 1 2 3 4 5 6 7 8 9 10 $ pgrep printcount $ Interestingly enough, only plain old C actually did what I wanted here. In Go and Python, we'd have to do a little work to not print the annoying error. But I don't think we want to check return codes from print in any of the languages.

mitchellh 13y ago

Both the original post and comments such as mine have made no mention comparing Go to other languages. We're just saying that Go itself is reliable. Not that others aren't or that Go is more reliable than others.

thrownaway2424 13y ago

I think most people who are pleased with the reliability of Go are coming from something like Python where unforeseen things pop up out of nowhere on rare code paths nobody anticipated. Things like a rare error handling path where some piece of code iterates over a string the author thought was a list, etc. Or perhaps they are coming from C++ where use-after-free or use-of-uninitialized or use-of-perversely-initialized are common at runtime. Go has none of that.

jbooth 13y ago
Or java/c# where exceptions tend to bubble all the way up the stack and where you have to to try/finally which can be harder to write safe code with than defer.
- danieldk 13y ago
  Or java/c# where exceptions tend to bubble all the way up the stack There is really no difference. In Java you have to decide at what level to catch exceptions. In Go you have to decide at what level to handle an error and just not return it. In fact, if you have to pass an error on level further up the stack, it's easier in Java. have to to try/finally which can be harder to write safe code with than defer. Why? I suppose that you are referring to the fact that you can put a defer right next to e.g. opening a file. But Java has the (arguably) nice(r) try-with-resources construct since Java 7: http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html http://docs.oracle.com/javase/tutorial/essential/exceptions/...
  - jbooth 13y ago
    I'm not a Java hater, I love it, but a lot of code tends to be written as just "throws IOException". I've written a lot of code like that. Go forces you to handle each error separately, which can be nice.
- pjmlp 13y ago
  defer is no different than using(C#), try-resources(Java), scope(D), with(Python).

corresation 13y ago

The comments thread on this makes me sort of sad. The comments are almost ancillary, but if I'm reading the original correctly it is saying that Go itself -- the compiler, the garbage collection, and the "standard library", is incredibly reliable. Which has been my impression as well -- after years with a number of other languages and platforms, my first impulse when hitting an unexpected issue is looking into the platform/compiler/etc, to discover those edge conditions that I need to navigate around. Go, however...when something doesn't work as I expected, at this point I have an extremely high confidence that it is something I've done wrong. That is really unexpected in such a young ecosystem.

steveklabnik 13y ago

The Go love makes a lot of sense when you consider it's out to replace Python and Ruby, and not other statically typed compiled languages. If you learned programming via Python, and then moved to Go, it would seem revelatory. If you've previously done a lot of statically typed work, it's much more meh.

kaib 13y ago
I'll counter your anecdotal evidence with my anecdotal evidence. I know a few systems guys who have three or more decades of experience with statically typed languages who prefer Go. :-)
- steveklabnik 13y ago
  I didn't say you shouldn't prefer it, just that it's not as big a deal.
burntsushi 13y ago
Not for me. I had previously done Haskell work, and I find Go to be awesome. And I still think Haskell is awesome. Weird, eh?
- steveklabnik 13y ago
  I didn't even say 'bad,' I said 'more meh.' Furthermore, I didn't say that liking go makes you hate other languages, or that you should hate go if you like other languages...
  - burntsushi 13y ago
    > I didn't even say 'bad,' I said 'more meh.' I didn't say "bad" either.................. I said "awesome", which is in stark contrast to "more meh"................ > Furthermore, I didn't say that liking go makes you hate other languages, or that you should hate go if you like other languages... I didn't say you did. My implication was that people don't have to fit your mold of the world: I enjoy programming in many different kinds of languages. i.e., I liked Go at the outset even though I had previously done significant work in a static typed language with a rich type system.

aaronblohowiak 13y ago

The explanation of why I like Go is best found in: "Less is exponentially more": http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

nostrademons 13y ago
Somewhat ironically, that is exactly the same philosophy that was embodied in Java when it came out, and Java has grown so that it's now mentioned in the same breath as C++ when compared to Go. I think what happens in all languages - indeed, in all engineering projects - is that people start using them, and then their design collides with the real world, and people start asking for new features to make their own lives better, and each additional feature makes the language incrementally better without costing much. But when this has been going on for 20 years, you have an accretion of features that don't quite hang together and collectively are a royal pain to deal with. Eventually enough folks get fed up with this state that a new language can gain critical mass, and the cycle starts over again. The only languages immune to this are ones that explicitly reject certain use-cases as out-of-scope, and can design accordingly. C, for example, remains a great little language because it doesn't pretend to shield you from the dangers of the hardware, and so it can remain both fast and simple because everyone who wants it to scale up to big complicated applications reaches for C++ or Java instead. Python remains great as long as you remember that it's a scripting language and don't pretend that it'll be fast or maintainable beyond a certain size.
- danieldk 13y ago
  But when this has been going on for 20 years, you have an accretion of features that don't quite hang together and collectively are a royal pain to deal with. Eventually enough folks get fed up with this state that a new language can gain critical mass, and the cycle starts over again. I agree, but Java the language hasn't become much more complicated. In fact, it's development has been quite glacial, one of the reasons that some JVM-minded people switch to Scala. Probably the larger problem is that Java (to the Python/Ruby and now Go crowd) became associated with applets and big and ugly frameworks that require heaps of XML. However, Java the language doesn't differ all that much from Go. Java is better in some respects (generics, checked exceptions) and Go is nicer in some respects (closures). However, Java has an insanely great runtime (JVM) that can be fully instrumented, supports hot code swapping (some natively, DCEVM, JRebel). It also has a zillion great libraries, good IDEs, great web frameworks (that don't require writing XML), etc. Go will be popular in start ups, etc. Some people will take it into big corps (as happened with Python and Ruby). But to be used widely in the industry, it needs everything and more than the JVM or .NET offer.

bsdetector 13y ago

> Given the comments here I think that I can finally understand somewhat why Go is taking off the way it is The comments here are incredibly biased in Go's favor, for whatever reason. On other forums it does not get the same spotlight, for instance it has been mostly dismissed on reddit and is rarely even discussed there at all (even on it's own subreddit).

cmccabe 13y ago

It seems like you missed a lot of the other things he said, such as "testing is built into the language," and "binaries are statically compiled and will work on any reasonable kernel." These may not be sexy features, but they are features that you need to actually make reliable programs. And frankly, yes, Go's approach to handling errors is a Big Deal. It's counter to the tendency of the last few years to move more and more error handling into exceptions. In retrospect, we can see that that was a mistake, similar to the "natural language programming" dead-end that led to COBOL and HyperCard. Challenging the exception-handling orthodoxy is absolutely something interesting and new. What makes Go so special other than the lack of deep class hierarchies? This is an "other than that, Mrs. Lincoln, how was the play?" type of comment. Go's type system is absolutely huge in terms of making it special. It would never have attracted the attention it did if it were just another Modula-3 rehash like Java, C++, D, etc.

masklinn 13y ago
> And frankly, yes, Go's approach to handling errors is a Big Deal. It's not. > It's counter to the tendency of the last few years to move more and more error handling into exceptions. Haskell says hi. Go's error handling is a step back not because it tries to avoid exceptions but because it's a crummy very slight improvement over C error handling. Contrary to what you believe, the world has moved on since then, even outside of exceptions-based error handling. > Challenging the exception-handling orthodoxy is absolutely something interesting and new. It absolutely is not new, and there is nothing interesting to the way Go did it (which is a significant downgrade of Erlang's way of handling errors) > Go's type system is absolutely huge in terms of making it special. You have not answered the question. > It would never have attracted the attention it did Of course it would, the attention it attracted is due to its backers, not to its intrinsic qualities (of which it has few, lost in a morass of decisions which would have been bad 30 years ago).

pjmlp 13y ago

> What makes Go so special other than the lack of deep class hierarchies? Google sponsored language with HN rockstars in their team.