7 ms·
I totally agree; I've "gone off Go" until they figure out (1) errors vs exceptions, and (2) generics. I have no problem with them saying "we're not Going there
by justinsb 13y ago
I totally agree; I've "gone off Go" until they figure out (1) errors vs exceptions, and (2) generics. I have no problem with them saying "we're not Going there", but if so I wish they would at least say that. Right now, I'm betting at least one of those positions will change, and it will have fairly big ramifications for any existing code (in the same way that Java 1.0 code still runs, but is rather different code).
- joncooper 13y agoWhat is there to figure out about errors vs exceptions? I think the Go position on that matter is very clear.
- justinsb 13y agoAs I understand it, the position is that there are error return codes _and_ exceptions. Error return codes are for bad stuff, Exceptions are for really bad stuff. So correct Go code pays the price twice: it should be exception-safe, _and_ you have to manually handle error codes.
- tptacek 13y agoGolang does not have exceptions. It has "panic", which, you can see from the name, is meant to end a program's execution and is presumably "recoverable" only so that programs can wind themselves down (more) gracefully.
- justinsb 13y agoYou say panic, I say exception :-) My concern is not nomenclature, but that correct code must handle paniceptions. And that it must also handle return value errors. Go code IMHO ends up spending a lot of code on error handling, I think because of this double taxation.
- tptacek 13y agoYou say "setjmp", I say "thread library".
- pcwalton 13y agoI think you're misunderstanding justinsb's point a little bit. To be concrete, you have to remember to use "defer" in Go to clean up resources and locks, or else someone trying to use "recover" won't handle panics properly. This won't unlock the mutex on panic, which is observable if someone is trying to recover(): func F() { mutex.Lock() ... do something here that panics ... mutex.Unlock() } But this will: func F() { mutex.Lock() defer mutex.Unlock() ... do something here that panics ... } This is basically the same set of hazards as maintaining exception-safety in C++ or Java. So in this regard panic is very much like an exception system. (Of course, it has very different idiomatic use.)
- ansible 13y ago... To be concrete, you have to remember to use "defer" in Go to clean up resources and locks, ... You should probably be using defer() all the time anyway, unless you have a good reason not to. It also helps with code evolution, in the cases where some yahoo adds a new return statement in the middle of a function.
- beatgammit 13y agoBest practices for try/catch may be similar to idiomatic defer, but it's not the same semantically. For example, there's no analog to this: try { ... do something that throws ... } catch (...) { ... deferred code } ... other code If you don't use `catch`, then I could agree that try/finally is the same as defer, but I would argue that defer is a much cleaner design since cleanup code is located next to the thing they're cleaning up. I think it's much easier to audit this: mutex.Lock() defer mutex.Unlock() Than this: mutex.Lock() try { ... code that panics } finally { mutex.Unlock() } Other languages also make a distinction here, for example Python's `with` and D's `scope` [1]. Also, it's trivial to make a `panic` that is unrecoverable: `go panic("broke your code, lol!!")`. This just cements the idea that `panic` is semantically different than exceptions, and should be treated as such. [1] - http://dlang.org/statement.html#ScopeGuardStatement http://dlang.org/statement.html#ScopeGuardStatement
- tptacek 13y agoI don't think they're "figuring out" exceptions; my understanding is, they're not going to happen. I am also not a fan of hyperliteral case-by-case error checking (it reminds me of my early C code), but it's A Style, one that the Golang team enthusiastically adopts, and it's unlikely to go anywhere.
- justinsb 13y agoExceptions are already in the language: panic/recover. Though discouraged, you can't assume they won't happen. To me, this seems like the "worst of both worlds". It doesn't feel like a final position to me, it feels like a 1.0 position.
- tptacek 13y agoYou can abuse "panic" to implement exceptions in Golang the way you can abuse "longjmp" to do that in C. The purpose of "panic" isn't for general-purpose exceptions. It's to panic the program.
- justinsb 13y agoIt's clear you shouldn't throw. But correct code must assume that any function you call might throw; which is why you should use defer blocks e.g. to release resources, instead of C-style "cleanup at the bottom of the function". (Defer is also prettier IMHO)
- tptacek 13y agoYou're not "throwing". You're "panicking".
- ithkuil 13y agoOr raising? That's just terminology. The behaviors of c++/java/python exceptions and Go panics are similar regardless of the name the keyword has in those language: The execution is suspended, the stack unwound until the first handler, the handler has access to a value that is "thrown". Stack information is preserved in order to print meaningful stack traces. C++/java/python have syntax sugar that performs a pattern match on the thrown object to decide whether to handle it or bubble it up, while in Go you do it manually, but other that that I don't see much of a difference in the mechanics of them to justify being so pedantic about the naming of the action.
- gnuvince 13y agoHere's what's going to happen: neither parametric polymorphism, nor exceptions are going to happen in Go. The answer in the FAQ is just PR bullshit; the designers of Go are not interested in having parametric polymorphism and that's the bottom line.
- 4ad 13y agoFWIW, Limbo, Go's ancestor from the same author, does have generics.
- enneff 13y agoYou can say that until you're blue in the face, but the fact is we continue to discuss generics to this day and are very much interested in including them in the language. Why do people keep ignoring me when I say this? I guess the idea that the Go team are a bunch of generics-hating curmudgeons is more compelling than the reality.
- andybalholm 13y agoProbably because a lot of Go users _are_ generics-hating curmudgeons :-) (even though the team aren't)
- codygman 13y agoPerhaps you should blog about "Generics in Go discussions"? Then you would have some proof and dispel mistruths about Go. I would also get excited, since reality seems like Go developers don't care that much about generics. However, I'm taking into account you said that they do :)