Hacker News Reader

Comment by charlieflowers | Hacker News Reader

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too).

I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful.

I don't know if any language can beat that list of tool chain benefits. Maybe I will give go a whirl.

View on HN

I thought it would be a deal breaker for me, too. C/C++/C#/Python have been my standard languages... but after coding in it for a while, I love it. You never have to worry if someone downstream is going to throw an exception make your function exit before it gets to the end. That means you can write robust code without needing a ton of try/catch everywhere, or using statements (from C#) or whatever.

Yes, there's some of this:

if f, err := io.Open("foo.txt"); err != nil {

   return err

} else {

   // use f

}

However, that's not really any more code than

try:

    f = open("foo")

    // use f

except IOError as e:

    return e // or throw, or whatever

Plus Go uses multiple returns everywhere, so you don't have to worry about errors being confused with actual data returned.

It's pretty awesome.

Don't bother with the else. Just continue with your code outside a nested block since the if returns.

in this case, f is locally scoped to the if/else statement since it's assigned inside the if statement... Probably most of the time I would actually assign it outside the if statement and then check it/return and not have the rest of the code indented.

Go supports panic/recover which is very similar to exceptions. Instead of wrapping a try...catch block around something, you get to handle exceptions every time they are about to cause a function to be exited.

This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value.

tl;dr: Go has exceptions, they are just a little different (IMO for the better).

I think the real value of panic/recover over try/catch is the vastly improved idiomatic usage. Only to be used in exceptional cases, and never to cross package boundaries.

I just find that so much more pleasant.

Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.

Although, another post above says it's not idiomatic, so I guess working with go means accepting the lack of an exception mechanism.

No, jlgreco had it exactly right.

Panic and recover are non-idiomatic; using them the way you would exceptions in Python is (stylewise, I mean) a little like using setjmp and longjmp for flow control in a C progam.

In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.

The reality is that Go does not have exceptions the way Python does. If you're writing idiomatic Go, you're manually checking errors.

> Panic and recover are non-idiomatic;

Exactly (and probably for a reason)

> In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.

Well, there's no real way to recover after such an assert (the C stdlib is undefined when you catch the SIGABRT, the stack is not guaranteed to be big enough to do anything, most I/O is not guaranteed to work, etc. -- really, very few uses for catching a SIGABRT). There is a way in Go, even if it is far less capable than your average "except .." clause in C++.

> The reality is that Go does not have exceptions the way Python does.

True. Some of us (e.g. me) think that's a big advantage. (I'm not implying you disagree - I don't know what your opinion is)

I'm not a fan of the lack of exceptions in Go, but it's not a dealbreaker for me. I feel like Go code is very cluttered and fussy. I don't love the language as a language. But as a tool for getting systems programming problems solved, it is pretty amazing, and I love working with it.

I think the only thing missing is a REPL as part of the tool chain. ipython and scala shell are so useful, especially when you're learning or just testing things out.

Agreed. The way I tend to use the repl in clojure is just to code up a script in vim and then %Eval the whole thing. Editor plugins for Go could compile-and-run, and know stuff like the working directory and the gopath, which could get you a bit closer without having to build a real REPL.

> Editor plugins for Go could compile-and-run

Yep, rolled my own here: http://github.com/metaleap/go-buildrun -- I use it with GoSublime on Ctrl+B (which I strongly suspect must have some repl-like feature anyway by now, but not sure) -- but works in any editor that lets you hook a key binding to an executable and pass it the current .go file's path.

Would something like this qualify as a REPL, or is it not quite so? https://github.com/shurcooL/Conception/tree/simple-live-edit...

I tend to always have a play.golang.org tab open but agree, an in-editor repl would be nice.

Even though I'm using GoSublime I haven't really dug into its plethora of feature, it might just have a repl in there...

I think the defer keyword more than makes up for the lack of exceptions. And you can panic, you are just not supposed to let it get out of your package; catch it and return the error.

Reply on news.ycombinator.com