Hacker News Reader

Comment by th0br0 | Hacker News Reader

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

View on HN

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.

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.

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

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.

defer is no different than using(C#), try-resources(Java), scope(D), with(Python).

try-resources is new in java, didn't realize that c# had using.

I wasn't claiming it was revolutionary, just that it's nice.

> try-resources is new in java, didn't realize that c# had using.

Since .NET 1.0 (2002)

Yeah, I thought while typing it "C# prob has this already" but couldn't be bothered to check.

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.

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.

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

I didn't say you shouldn't prefer it, just that it's not as big a deal.

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?

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

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

> If you've previously done a lot of statically typed work, it's much more meh.

Specially when being old enough to remember when all your peers used Modula-2 and Turbo Pascal.

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

> What makes Go so special other than the lack of deep class hierarchies?

Google sponsored language with HN rockstars in their team.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

C is anything but simple, given the amount of undefined behavior it has.

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.

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.

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

Reply on news.ycombinator.com