5 ms·

Isn’t there a Rob Pike quote for these? "Who cares? Shut up" It’s in the context of concerns from newer developers who don’t focus on what’s important. This

by ctvo 5y ago

Isn’t there a Rob Pike quote for these? "Who cares? Shut up" It’s in the context of concerns from newer developers who don’t focus on what’s important. This is the same blog that gave us code smells, abstract more to hide it (https://jesseduffield.com/Type-Keys-Revisited https://jesseduffield.com/Type-Keys-Revisited) -- only to point out the possibly differing perspectives on software development. There’s a philosophy to the language that’s very clearly defined. You have many options these days on what you write in. You’re not changing how Go does error handling because you think it’s needlessly verbose.

jesseduffield 5y ago
That definitely sounds like Rob Pike. As for changing how Go does error handling, there is actually a proposal in motion to do exactly this, with support among both devs and the language maintainers: https://github.com/golang/go/issues/21182#issuecomment-542416036 https://github.com/golang/go/issues/21182#issuecomment-54241...
- ctvo 5y ago
  That looks like lukewarm support at best, on something that hasn't moved beyond an issue with little details, and is closed. I would not represent that as anything else. The entire process is captured here: https://github.com/golang/proposal https://github.com/golang/proposal
  - jesseduffield 5y ago
    I'm not sure what you mean when you say closed: the proposal is clearly open, and the latest comment asking if anybody has issues with the proposal has no downvotes. That sounds promising to me. At the very least, it's clear that the language maintainers see an issue with the current error handling, given how much time they've spent working on proposals. The community also clearly cares: see https://twitter.com/_rsc/status/1146129898383302656 https://twitter.com/_rsc/status/1146129898383302656 Also, I see you amended your original comment with a jab against me for the type keys post. Not sure what to tell you there, I posted something, absorbed the feedback, and incorporated that into the blog. If you have specific issues with the latest post please let me know.
    - ctvo 5y ago
      > Also, I see you amended your original comment with a jab against me for the type keys post. I didn't realize you were the same person who wrote that blog post, and I edited it to include it when I realized. I linked your amended version, not your initial version if that's of any worth. And you're correct it's not closed. I still stand by that particular proposal is going nowhere. You can make any proposal you want. It hasn't even moved to the design stage yet in 3 years, so I'm not sure why it's something you hang on to as a signal error handling is changing. Take generics for example, and the years (decade) of work that it took. This is unsolicited blog feedback: Your blog and writing style doesn't read like it comes from a place of humility and learning, but from a place of authority. Sometimes that's OK, but in your case, feels unwarranted. And the constant push to get it on to HN or Reddit or N other platforms so it can spread... Thought leadership as an aspirational goal has never been something I look for in blogs I read (I recoil and go elsewhere when I sense this is the goal). I understand it's hard work, and you want others to see it, but just someone else's perspective. Some blogs that I really enjoy (and I hope others emulate so I'm sharing): - http://neugierig.org/software/blog/ http://neugierig.org/software/blog/ - https://brooker.co.za/blog/ https://brooker.co.za/blog/
      - jesseduffield 5y ago
        Thanks for the feedback: I've found that most of the learning I've done has been thanks to feedback from reddit/hackernews so I'm very much dependent on it to know whether I'm off the mark. In terms of authoritative tone, I agree: some posts are stated in confident terms because I _am_ confident, but of course I'm learning to adjust that confidence level based on feedback.
Cthulhu_ 5y ago
It does apply though. If you think error handling in Go is too verbose or boring, you're not solving a real problem. If you're trying to come up with design patterns and strategies - as described in the article - to see if you can shave off some code (at the cost of complexity and non-idiomatic code), you're not solving a real problem. Software is never about the low level nitty gritty, and in these cases it's better to stick with what people expect to see / read. Don't make people think. I'm not smart enough to read your interesting error checking.

by ctvo 5y ago

jesseduffield 5y ago

That definitely sounds like Rob Pike. As for changing how Go does error handling, there is actually a proposal in motion to do exactly this, with support among both devs and the language maintainers: https://github.com/golang/go/issues/21182#issuecomment-542416036 https://github.com/golang/go/issues/21182#issuecomment-54241...

ctvo 5y ago
That looks like lukewarm support at best, on something that hasn't moved beyond an issue with little details, and is closed. I would not represent that as anything else. The entire process is captured here: https://github.com/golang/proposal https://github.com/golang/proposal
- jesseduffield 5y ago
  I'm not sure what you mean when you say closed: the proposal is clearly open, and the latest comment asking if anybody has issues with the proposal has no downvotes. That sounds promising to me. At the very least, it's clear that the language maintainers see an issue with the current error handling, given how much time they've spent working on proposals. The community also clearly cares: see https://twitter.com/_rsc/status/1146129898383302656 https://twitter.com/_rsc/status/1146129898383302656 Also, I see you amended your original comment with a jab against me for the type keys post. Not sure what to tell you there, I posted something, absorbed the feedback, and incorporated that into the blog. If you have specific issues with the latest post please let me know.
  - ctvo 5y ago
    > Also, I see you amended your original comment with a jab against me for the type keys post. I didn't realize you were the same person who wrote that blog post, and I edited it to include it when I realized. I linked your amended version, not your initial version if that's of any worth. And you're correct it's not closed. I still stand by that particular proposal is going nowhere. You can make any proposal you want. It hasn't even moved to the design stage yet in 3 years, so I'm not sure why it's something you hang on to as a signal error handling is changing. Take generics for example, and the years (decade) of work that it took. This is unsolicited blog feedback: Your blog and writing style doesn't read like it comes from a place of humility and learning, but from a place of authority. Sometimes that's OK, but in your case, feels unwarranted. And the constant push to get it on to HN or Reddit or N other platforms so it can spread... Thought leadership as an aspirational goal has never been something I look for in blogs I read (I recoil and go elsewhere when I sense this is the goal). I understand it's hard work, and you want others to see it, but just someone else's perspective. Some blogs that I really enjoy (and I hope others emulate so I'm sharing): - http://neugierig.org/software/blog/ http://neugierig.org/software/blog/ - https://brooker.co.za/blog/ https://brooker.co.za/blog/
    - jesseduffield 5y ago
      Thanks for the feedback: I've found that most of the learning I've done has been thanks to feedback from reddit/hackernews so I'm very much dependent on it to know whether I'm off the mark. In terms of authoritative tone, I agree: some posts are stated in confident terms because I _am_ confident, but of course I'm learning to adjust that confidence level based on feedback.

Cthulhu_ 5y ago

It does apply though. If you think error handling in Go is too verbose or boring, you're not solving a real problem. If you're trying to come up with design patterns and strategies - as described in the article - to see if you can shave off some code (at the cost of complexity and non-idiomatic code), you're not solving a real problem. Software is never about the low level nitty gritty, and in these cases it's better to stick with what people expect to see / read. Don't make people think. I'm not smart enough to read your interesting error checking.