undefined | Better HN

0 pointsXorNot2y ago0 comments

This seems like a distinction without a difference. In reality, in code, I'm still doing something like `if (!result.failed) { do the thing } else { do the other thing }`

Like...this makes no difference to my ergonomics at all. In many cases it's arguably worse because now 1 token is potentially representing two very different types I want to deal with.

The primary benefit to me seems like it's more to do with the ease of generic code handling: everything can be Results, and then I can evaluate them all to see if any of them are errors, which in turn makes failing out of many different operations easier - I'm not handling a file type, a string, some numbers etc.

0 comments

mkehrt2y ago

In rust the type system enforces you check the error. In go, it doesn't. (Because rust error types are enums/sums and go error types are structs/products). This seems like a huge difference.

> In many cases it's arguably worse because now 1 token is potentially representing two very different types I want to deal with.

Yes, that's what an enum/sum type is? That's the whole point.

philosopher12342y ago

In rust it is not possible to use incorrectly, and in go it is, sure. But whether it is possible or not is only one dimension. Does it matter that it’s possible to misuse errors in Go if it virtually never happens?

I just don’t find the point about what is possible interesting. The other trade offs around readability, ergonomics, and so on seem more impactful.

nulld3v2y ago

> virtually never happens

Ah yes, like it "never happened" in the Kubernetes project?

- https://github.com/kubernetes/kubernetes/pull/60962

- https://github.com/kubernetes/kubernetes/pull/80700

- https://github.com/kubernetes/kubernetes/pull/27793

- https://github.com/kubernetes/kubernetes/pull/110879

I can find tons of these, just by searching any larger Go project's Github.

Here's one from docker too: https://github.com/moby/moby/pull/10321

What about from CockroachDB? https://github.com/cockroachdb/cockroach/pull/74743 Even the linter missed this one!

philosopher12342y ago

Of course it happens, I’ve done it. But it’s obvious, it’s the least interesting aspect of the debate. And I think it is less impactful than e.g making exceptions easy for devs to ignore.

1 more reply

earthboundkid2y ago

Kubernetes is a huge project and not idiomatically written, so it would be shocking if it didn’t exhibit everything that can go wrong with Go.

CockroachDB is a better example.

1 more reply

consilient2y ago

> Does it matter that it’s possible to misuse errors in Go if it virtually never happens? I just don’t find the point about what is possible interesting.

If you knew for sure that it virtually never happened, maybe not. But you don't. At best you know that a few particular individuals you're familiar with never mess it up (but then again, consider the people who "virtually never" write incorrect C). You can't trust random packages you haven't vetted, and you certainly can't trust code written by your junior software engineers.

> The other trade offs around readability, ergonomics, and so on seem more impactful.

Sum types have significantly better ergonomics. `(Result | null, Error | null)` takes four branches to handle properly, whereas `Either Result Error` takes two. And of course things get much worse once you're more than one layer deep, which in a language as procedural as Go you almost always are.

go_explore_52y ago

It depends if you find value in exhaustive pattern matching.

From years of using C's switch statements, I'm not going back.

j / k navigate · click thread line to collapse

0 comments

mkehrt2y ago

In rust the type system enforces you check the error. In go, it doesn't. (Because rust error types are enums/sums and go error types are structs/products). This seems like a huge difference.

> In many cases it's arguably worse because now 1 token is potentially representing two very different types I want to deal with.

Yes, that's what an enum/sum type is? That's the whole point.

philosopher12342y ago

I just don’t find the point about what is possible interesting. The other trade offs around readability, ergonomics, and so on seem more impactful.

nulld3v2y ago

> virtually never happens

Ah yes, like it "never happened" in the Kubernetes project?

- https://github.com/kubernetes/kubernetes/pull/60962

- https://github.com/kubernetes/kubernetes/pull/80700

- https://github.com/kubernetes/kubernetes/pull/27793

- https://github.com/kubernetes/kubernetes/pull/110879

I can find tons of these, just by searching any larger Go project's Github.

Here's one from docker too: https://github.com/moby/moby/pull/10321

What about from CockroachDB? https://github.com/cockroachdb/cockroach/pull/74743 Even the linter missed this one!

philosopher12342y ago

Of course it happens, I’ve done it. But it’s obvious, it’s the least interesting aspect of the debate. And I think it is less impactful than e.g making exceptions easy for devs to ignore.

1 more reply

earthboundkid2y ago

Kubernetes is a huge project and not idiomatically written, so it would be shocking if it didn’t exhibit everything that can go wrong with Go.

CockroachDB is a better example.

1 more reply

consilient2y ago

> Does it matter that it’s possible to misuse errors in Go if it virtually never happens? I just don’t find the point about what is possible interesting.

> The other trade offs around readability, ergonomics, and so on seem more impactful.

go_explore_52y ago

It depends if you find value in exhaustive pattern matching.

From years of using C's switch statements, I'm not going back.

j / k navigate · click thread line to collapse