4 ms·

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 be

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.

felixge 14y ago
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).
- jlgreco 14y ago
  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.
  - charlieflowers 14y ago
    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.
    - charlieflowers 14y ago
      Although, another post above says it's not idiomatic, so I guess working with go means accepting the lack of an exception mechanism.
      - pkulak 14y ago
        No, jlgreco had it exactly right.
- tptacek 14y ago
  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.
  - beagle3 14y ago
    > 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)
    - tptacek 14y ago
      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.
geoka9 14y ago
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.
- cerales 14y ago
  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.
  - dualogy 14y ago
    > Editor plugins for Go could compile-and-run Yep, rolled my own here: http://github.com/metaleap/go-buildrun 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.
- shurcooL 14y ago
  Would something like this qualify as a REPL, or is it not quite so? https://github.com/shurcooL/Conception/tree/simple-live-editor https://github.com/shurcooL/Conception/tree/simple-live-edit...
- dualogy 14y ago
  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...
NateDad 14y ago
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.
- jgeralnik 14y ago
  Don't bother with the else. Just continue with your code outside a nested block since the if returns.
  - NateDad 14y ago
    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.
pkulak 14y ago
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.

felixge 14y ago

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

jlgreco 14y ago
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.
- charlieflowers 14y ago
  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.
  - charlieflowers 14y ago
    Although, another post above says it's not idiomatic, so I guess working with go means accepting the lack of an exception mechanism.
    - pkulak 14y ago
      No, jlgreco had it exactly right.
tptacek 14y ago
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.
- beagle3 14y ago
  > 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)
  - tptacek 14y ago
    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.

geoka9 14y ago

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.

cerales 14y ago
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.
- dualogy 14y ago
  > Editor plugins for Go could compile-and-run Yep, rolled my own here: http://github.com/metaleap/go-buildrun 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.
shurcooL 14y ago
Would something like this qualify as a REPL, or is it not quite so? https://github.com/shurcooL/Conception/tree/simple-live-editor https://github.com/shurcooL/Conception/tree/simple-live-edit...
dualogy 14y ago
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...

NateDad 14y ago

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.

jgeralnik 14y ago
Don't bother with the else. Just continue with your code outside a nested block since the if returns.
- NateDad 14y ago
  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.

pkulak 14y ago

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.