Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

I'm not in love with this aspect of Go either, and I also find that the idiom for dealing with it (multiple return values and multi-statement if conditional clauses) doesn't play well with Go's scoping rules, so that I find myself regularly having to decide between cleaner conditional or an explicit variable declaration. I also don't love how it makes my code look like my teenage-years C code.

But I also think this is a very silly reason to adopt or not adopt a tool. No other approach to error handling is less fraught.

If Python is your only language, Go or something like Go is probably a very useful thing to have in your back pocket: compiled native binaries, fine-grained control over memory layout, and a simple and effective concurrency model is a good thing to have in one package.

There are a lot of things that annoy me about Go (and for that matter Python, which irritates me for very similar reasons). What I tell myself to get over that and keep an open mind is, Go may not be my idea of an elegant language (yet; I'm still learning to appreciate it), but it is an excellent tool. I can get over the language stuff if the tool works well enough, and Go seems to for me.

Incidentally, who "leaves" a language? I have a very hard time seeing how, even from the label on the tin, anyone could believe Go is a great solution for every problem. Python sure as hell isn't either.

Incidentally, who "leaves" a language?

I started programming almost 30 years ago. Some languages I haven't touched in decades: BASIC, Fortran or Pascal. These days every time I have to use Java I hope it's the last. On the other hand, I used C for the first time 25 years ago. I don't use it very often but I wouldn't say I've left it.

So yes, people leave languages. And in many cases for good reason.

What a refreshingly even-handed perspective. And you even talk about semantics instead of syntax.

Go isn't particularly elegant in my opinion, either, at least not compared to a lot of languages. But it's pretty good for getting stuff done, and handles a lot of common problems in a way that is direct and simple. I can perceive that utilitarianism as a form of elegance.

> No other approach to error handling is less fraught.

The thing that kills me about Go's error handling is you return error AND value all the time. It's like an Either that always has Left and Right. I think it's a bummer, especially coming from a group that has developed languages in the past.

I imagine that this is to keep compatibility with C. And also, this ensures that when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL.

I'm not sure how, C doesn't have multiple return values either. I also don't really understand the second part. How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?

>> when a Left value is accidentally read as a Right one, you don't get a "random" bit pattern due to type punning, but a correct (albeit meaningless) value such as NULL

> How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?

You get deterministic failure modes instead of dragons flying out of your nose.

Also assigning error in a variable ignoring it sticks out a lot more. The single-return value C version doesn't tell you if it can return failure or not.

edit: fixed quoting

> You get deterministic failure modes instead of dragons flying out of your nose

What Go currently has does not solve this problem, which is what I'm pointing out. Your argument is basically "not handling the error Looks Bad". Mine is "It should be impossible to do wrong". Something like ADT's would have been very welcomed, then we could just have a classy option type or either type.

Well, the choice is between structures or tagged unions.

I'm not a Go user, but if I understand correctly ("It's like an Either that always has Left and Right."), functions return a structure with both an error code and a value.

To wrap a C function into a Go function with this signature, you can initialize a structure with { code: success; value:f() }; and then of course error checking has to be done C-style (errno, lib_last_error(), etc).

The problem with tagged unions is that when you access the wrong field (when it's not enforced by the language), everything can happen : you can build ill-formed values, jump to random places, etc. Having an explicit NULL in that cases is better.

In a nutshell, unsafe tagged unions < explicit NULLs < safe tagged unions.

Go actually returns true multiple values, not a structure. You can't assign it to a single variable, for example, you actually have to assign it to N variables, with N being the number of values the function returns.

By "unsafe tagged unions" you mean "untagged unions" (or ad hoc runtime-tagged unions)?

No other approach to error handling is less fraught.

CL's condition system is less fraught: http://www.gigamonkeys.com/book/beyond-exception-handling-co...

Do you mean that restarts help the clutter and distraction that error handling brings? Or is there something else that makes the condition system less fraught than exceptions?

It's less fraught than exceptions in the sense that it offers more options for recovery. With "regular" exceptions by the time your handler executes the stack's been unwound and the context of the error vanished; you only have what information the exception itself provides. Not so with CL's exceptions.

Some time ago, I left COBOL and RPG-III, thanks.

Reply on news.ycombinator.com