>> difficulty of writing if err != nil
>Literally the simplest way to deal with errors (cognitively and character wise). Since AI autocomplete entered the scene, typing this repetitive (for a reason) pattern became not a problem at all (I'm not even talking about post Claude Code era)
I agree with you. I don't have problems with the `if err!=nil` syntax.
From my post:
> It’s become something of a meme to bemoan the supposed difficulty of writing if err != nil. I actually won’t make that point because I think it is a very surface level point that has been talked about to death and *I don’t think the ‘verbosity’ of this code snippet is such an issue.*
I apologize if my language was ambiguous on whether or whether not I had a problem with that syntax.
>In his example author could easily use his `progError` type instead.
I agree, but it was my impression that type erasure was more idiomatic. I should have made it clear that I was criticizing that idiom, not the language.
>Well, no. See for wrap/unwrap functionality https://go.dev/blog/go1.13-errors
You are right. I should have done my research on that before writing that point. I still think that downcasting isn't the most elegant solution because it defeats the point of using the opaque return type but I agree that it is nowhere near as much of a problem as I thought it was.
I agree with you. I don't have problems with the `if err!=nil` syntax.
From my post: > It’s become something of a meme to bemoan the supposed difficulty of writing if err != nil. I actually won’t make that point because I think it is a very surface level point that has been talked about to death and *I don’t think the ‘verbosity’ of this code snippet is such an issue.*
I apologize if my language was ambiguous on whether or whether not I had a problem with that syntax.
>In his example author could easily use his `progError` type instead.
I agree, but it was my impression that type erasure was more idiomatic. I should have made it clear that I was criticizing that idiom, not the language.
>Well, no. See for wrap/unwrap functionality https://go.dev/blog/go1.13-errors
You are right. I should have done my research on that before writing that point. I still think that downcasting isn't the most elegant solution because it defeats the point of using the opaque return type but I agree that it is nowhere near as much of a problem as I thought it was.