Our Experience with Golang

<p>This blog post is a reflection on our recent experience of porting a reasonably large (~30KLOC) JRuby application to Google Go, talking about the many things we liked about the language and ecosystem, and the couple of things that I found grating about it.</p> <p><a href="https://www.scriptrock.com/blog/our-experience-with-golang" rel="nofollow">https://www.scriptrock.com/blog/our-experience-with-golang</a></p> <hr/>**评论：**<br/><br/>playa_1: <pre><p>We&#39;ve discussed this at least a few times before.</p> <p>Here is the last one: <a href="https://www.reddit.com/r/golang/comments/3kwb08/scriptrock_our_experience_with_golang/" rel="nofollow">https://www.reddit.com/r/golang/comments/3kwb08/scriptrock_our_experience_with_golang/</a></p></pre>weberc2: <pre><blockquote> <p>&#34;Why is every line an if statement?&#34; If you deduct error handling, Go shouldn&#39;t have more if statements than other languages. Although some of the generics-workarounds (type assertions, etc) may introduce if statements that wouldn&#39;t be in languages with more conventional generic programming mechanisms.</p> </blockquote></pre>thepciet: <pre><p>The error verbosity kinda goes away once you get into your own packages and directly making concurrent stuff.</p> <p>Handling HTTP and HTML has tons of error cases to deal with and that&#39;s what almost every Go programmer is going to start with I&#39;d assume.</p> <p>Full Disclosure: I like having error handling right there anyway. Exceptions are such a mess.</p></pre>weberc2: <pre><p>Agreed. The people who are annoyed by the if statements don&#39;t quite realize that exception-languages don&#39;t have that because they just sweep the problems under the rug.</p></pre>thepciet: <pre><p>Well, the programmer does the sweeping. I personally haven&#39;t used exceptions as much as immediate error objects. There must be good ways to use exceptions.</p></pre>weberc2: <pre><p>I&#39;m not sure if you misunderstood my analogy or if I&#39;m misunderstanding your response, but by &#34;exceptions sweep problems under the rug&#34;, I meant that exceptions are hidden until someone explicitly goes looking for them (via a try/catch higher in the callstack). This is in opposition to returned errors which must be dealt with explicitly at every level, which means ignoring the error is almost an explicit action (although Java incorporates exceptions into the method signature, and failing to handle them is a compiler error, which is pretty cool).</p></pre>thepciet: <pre><p>I just meant that it is possible to successfully, correctly, and maintainably implement traditional try/catch exception blocks. These are just computers tools us humans wire together.</p> <p>I do agree with all of your points and would much rather be presented with local handling over digging for out of order blocks of code. But no code is right for every use.</p></pre>heptara: <pre><p>I don&#39;t get why people don&#39;t wrap their calls in an error handler function, then they never have to look at a bunch of if error blocks. They can even have the same function handle multiple errors and then it&#39;s just like an exception handler.</p></pre>fxnn: <pre><p>Agreed. I&#39;d recommend those blog.golang.org posts for some ideas on how to handle errors nicely:</p> <ul> <li><a href="http://blog.golang.org/errors-are-values" rel="nofollow">http://blog.golang.org/errors-are-values</a></li> <li><a href="http://blog.golang.org/error-handling-and-go" rel="nofollow">http://blog.golang.org/error-handling-and-go</a></li> </ul> <p>Especially the former one is a very nice approach, as I think. That&#39;s the nice thing about all this: We learn some pretty new ways to do stuff.</p></pre>