<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>KirinDave</author><text>I guess then I have to ask, why would try() make that worse?&lt;p&gt;Because I can&amp;#x27;t stand Golang error handling. It&amp;#x27;s repetitive, it&amp;#x27;s error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced.&lt;p&gt;On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be confident I can just use an error handling strategy. The only complexities appear, as with everyone else, when we have asynchronous code.&lt;p&gt;So I don&amp;#x27;t mean to disagree with your feelings, but they&amp;#x27;re sure not mine and they&amp;#x27;re part of why I don&amp;#x27;t use Golang. I was excited about try() because it at least addressed the most tedious part.</text><parent_chain><item><author>natefinch</author><text>Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code.  Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I&amp;#x27;d written, even though I was a newbie at Go and a veteran of the other languages.</text></item><item><author>KirinDave</author><text>&amp;gt; Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.&lt;p&gt;So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics.&lt;p&gt;That lead to a world where folks felt &amp;quot;forced&amp;quot; to use Java, and that&amp;#x27;s a sticky label that&amp;#x27;s difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.</text></item><item><author>wybiral</author><text>This hits at something fundamental about Go, which is what I like the most about it...&lt;p&gt;It&amp;#x27;s a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you&amp;#x27;re forced to carry them up the chain.&lt;p&gt;Do I particularly &lt;i&gt;like&lt;/i&gt; managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.&lt;p&gt;The same goes with the Go ecosystem and tools. You might not like how gofmt forces your code or the documentation conventions used by golint but the fact that we all use the same convention and documentation is awesome and it&amp;#x27;s what allows things like godoc.org. I think the proverb is &amp;quot;gofmt&amp;#x27;s style is no one&amp;#x27;s favorite, yet gofmt is everyone&amp;#x27;s favorite&amp;quot;.&lt;p&gt;And things like the lack of abstractions and generics are what create a community that&amp;#x27;s less reliant on dependencies. &amp;quot;A little copying is better than a little dependency&amp;quot; and you can see it in stark contrast to something like the JS community with its require(&amp;#x27;left-pad&amp;#x27;) NPM ecosystem.&lt;p&gt;So, yeah, I like that they didn&amp;#x27;t fragment the community around something as arbitrary as this. And I get that some people won&amp;#x27;t like it, just as they don&amp;#x27;t like the lack of generics, but there is strength in some of these approaches that isn&amp;#x27;t immediately obvious.</text></item></parent_chain></comment><story><title>Declined Proposal: A built-in Go error check function, “try”</title><url>https://github.com/golang/go/issues/32437#issuecomment-512035919</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>kazinator</author><text>Did you know where every page fault would happen, and manually check every memory access and fix the situation?&lt;p&gt;You didn&amp;#x27;t have to because there is an precise, robust non-checked exception handling system which takes care of that: the hardware catches the situation, dispatches a handler in the operating system which fixes it and re-starts your program at the original machine instruction to try the memory access again.</text><parent_chain><item><author>natefinch</author><text>Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code.  Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I&amp;#x27;d written, even though I was a newbie at Go and a veteran of the other languages.</text></item><item><author>KirinDave</author><text>&amp;gt; Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.&lt;p&gt;So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics.&lt;p&gt;That lead to a world where folks felt &amp;quot;forced&amp;quot; to use Java, and that&amp;#x27;s a sticky label that&amp;#x27;s difficult to remove. I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics.</text></item><item><author>wybiral</author><text>This hits at something fundamental about Go, which is what I like the most about it...&lt;p&gt;It&amp;#x27;s a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you&amp;#x27;re forced to carry them up the chain.&lt;p&gt;Do I particularly &lt;i&gt;like&lt;/i&gt; managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects.&lt;p&gt;The same goes with the Go ecosystem and tools. You might not like how gofmt forces your code or the documentation conventions used by golint but the fact that we all use the same convention and documentation is awesome and it&amp;#x27;s what allows things like godoc.org. I think the proverb is &amp;quot;gofmt&amp;#x27;s style is no one&amp;#x27;s favorite, yet gofmt is everyone&amp;#x27;s favorite&amp;quot;.&lt;p&gt;And things like the lack of abstractions and generics are what create a community that&amp;#x27;s less reliant on dependencies. &amp;quot;A little copying is better than a little dependency&amp;quot; and you can see it in stark contrast to something like the JS community with its require(&amp;#x27;left-pad&amp;#x27;) NPM ecosystem.&lt;p&gt;So, yeah, I like that they didn&amp;#x27;t fragment the community around something as arbitrary as this. And I get that some people won&amp;#x27;t like it, just as they don&amp;#x27;t like the lack of generics, but there is strength in some of these approaches that isn&amp;#x27;t immediately obvious.</text></item></parent_chain></comment><story><title>Declined Proposal: A built-in Go error check function, “try”</title><url>https://github.com/golang/go/issues/32437#issuecomment-512035919</url></story>