81–90 of 94 posts
5 years ago I would be more sympathetic to this proposal. But now we have LLM copilots, so writing boilerplate in any language is dramatically more optional. And I don't see this proposal significantly improving readability of the code.
Earlier quoted context omitted.
> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to…
The distinction you're not acknowledging is that with pattern matching + algebraic data types you can't do anything with the payload without handling the error case. (You need to write a pattern match to extract the value, and the match needs to be exhaustive.) With a separate error value, like in Go, that's no longer the case. The code for handling the error and the code for doing something with the payload are tota…
Consider:
func GetData() (*Data, error)
Success/failure values are logically intertwined by convention in some other languages, but you can't reasonably take idioms from other languages and slap them down on Go like that. Just as you cannot reasonably do so in reverse. Different languages express things differently. That's what makes them different.
Is that the disconnect here? That you believe all languages share the exact same idioms?
Earlier quoted context omitted.
> Like in the same way you might forget to write pattern matching code? This is a lengthy response to seemingly ignore, or miss, the point being made. It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. Conversely, it is possible and easy with Go. Nothing you have said acknowledges this.
> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to…
I can't tell if you're being intentionally obtuse. It behooves you to research the topic being discussed, instead of writing long-winded snarky posts.
It is not worth continuing this discussion unless you can demonstrate, with explicit code examples, what you think we're talking about, and why you believe it is incorrect.
Earlier quoted context omitted.
> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to…
> I have read this exact claim before, for what it is worth. Did you end up here simply because you repeated what you saw elsewhere without actually thinking about it? I can't tell if you're being intentionally obtuse. It behooves you to research the topic being discussed, instead of writing long-winded snarky posts. It is not worth continuing this discussion unless you can demonstrate, with explicit code examples, w…
Earlier quoted context omitted.
> It is literally impossible to "forget" if you have pattern matching + algebraic data types/enum/unions. No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time. There fundamentally has to…
> I have read this exact claim before, for what it is worth. Did you end up here simply because you repeated what you saw elsewhere without actually thinking about it? I can't tell if you're being intentionally obtuse. It behooves you to research the topic being discussed, instead of writing long-winded snarky posts. It is not worth continuing this discussion unless you can demonstrate, with explicit code examples, w…
func foo(bar func() error) bool {
err := bar()
if err != nil {
return true
}
return false
}
func TestFooReturnsTrueWhenBarReturnsError(t *testing.T) {
if foo(func() error { return nil }) {
t.Error("expected foo to return false")
}
if !foo(func() error { return errors.New("error") }) {
t.Error("expected foo to return true")
}
}
This https://go.dev/play/p/k8zDQj5knaj is what I envision you are talking about, but clearly that cannot be it. As you can see it loudly proclaims that I "forgot", making this forgetfulness idea you have come up with impossible. So, what it is that you actually have in mind?
Earlier quoted context omitted.
> You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake. While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case?
> While I also don't like Go's error handling approach I thought Go compiler gives an error if a variable is unused, in this case `err`. Is this not the case? This isn't foolproof. If you're calling multiple methods and reusing `err` it won't give an error because it's technically not unused.
Earlier quoted context omitted.
The distinction you're not acknowledging is that with pattern matching + algebraic data types you can't do anything with the payload without handling the error case. (You need to write a pattern match to extract the value, and the match needs to be exhaustive.) With a separate error value, like in Go, that's no longer the case. The code for handling the error and the code for doing something with the payload are tota…
What is to be acknowledge, exactly? By Go convention, values are to always be "useful", so the error is only significant if you need to use the error value for some reason. They are not logically intertwined like you have postulated. Consider: func GetData() (*Data, error) Both returned values are independently observable. Unless you need the error value for your particular situation, the Data variable contains every…
But you've been making arguments like the following:
> Like in the same way you might forget to write pattern matching code?
> No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching on the result at the exact same moment in time.
And that is just disingenous. That's not you having a different opinion on something that's a matter of taste. That's you repeatedly trying to suggest that both forms of error handling are equally likely to suffer from somebody accidentally failing to handle the error.
And obviously that's not true, exactly because the returned values are logically separate in Go and aren't in the other lanuages. That is, in typical Go code, if you assign the error to err but omit the if err != nil {} boilerplate, the code will typically compile. (It'll compile, because the error variable is basically always named err, and most functions will have other references to that variable, such that the "unused variable" compiler diagnostics don't trigger.)
Earlier quoted context omitted.
Im not really following this. Only somewhat familiar with Go. The pattern we're talking about is returning errors and having to explicitly check for them, right? How does the lack of "algebraic data types/enum/unions" make this pattern un-ergonomic?
Error patterns aren't type checked in Go. So you can forget to check an error, not notice, and ship a bug. It compounds with features like zero values and pointers-as-null to make these bugs either subtle or not subtle, but discoverable only at runtime.
It saddens me tbat the default error handler is "return err", as opposed to something that appends context/stack trace. We've converted a few scripts and webapps from Python to Go, and if one does default handling ("return err") the error logs became significantly less useful, compared to exception backtraces. Yes, there are ways around it, but most tutorials don't show them.
Earlier quoted context omitted.
What is to be acknowledge, exactly? By Go convention, values are to always be "useful", so the error is only significant if you need to use the error value for some reason. They are not logically intertwined like you have postulated. Consider: func GetData() (*Data, error) Both returned values are independently observable. Unless you need the error value for your particular situation, the Data variable contains every…
No, all languages don't need to share the same idioms. But you've been making arguments like the following: > Like in the same way you might forget to write pattern matching code? > No, it's entirely possible to forget. That should be obvious. It is a functional necessity for you to be able to forget as you can only type so much at a time. You cannot possibly write code to call a function and perform pattern matching…
It may compile, but won't pass the test. Are you under the impression that a developer suddenly becomes blind after compilation and somehow magically won't see that the test failed? That doesn't happen. How are you going to forget? In reality, your forgetfulness is going to be made loud and clear. –– We offered a challenge to another account. He failed miserably, as did I, but maybe you can do better? https://news.ycombinator.com/item?id=42865349
And, before you even think it, no, you cannot skip that test in another language with pattern matching. There is nothing pattern matching can do to help you with what it is testing. It should be obvious to you that even if you do successfully pattern match, you might, for example, "forget" to return the right value. The documentation and additional checks and balances are required either way. The type system does not save you here.
And, before you even think it, no, "but what if I am a dummy who doesn't understand his tools or how to program???" doesn't work either as if you are that dummy then you aren't going to use the right types to activate the pattern matching semantics of which we speak, so pattern matching is not going to notice anyway. There is a necessary assumption in this discussion that you understand the tools, idioms, and software engineering in general. We cannot even meaningfully talk about pattern matching alone without that assumption.
So, how are you going to forget, exactly? You won't. This isn't a real thing. Pattern matching is cool, though, with many real benefits. It is funny that someone decided to focus on a made up benefit instead of what makes it actually great. But this is a commonly repeated trope so I'm sure we got here because he blindly repeated it without thinking about it for even a millisecond.