<story><title>Why I Like Go</title><url>https://gist.github.com/freeformz/4746274</url></story><parent_chain></parent_chain><comment><author>graue</author><text>These points are all very true, and I admit I haven&apos;t done more with Go yet than play around. But there are a few reasons I feel I &lt;i&gt;don&apos;t&lt;/i&gt; like Go, or at least, there are warts that will probably limit how much I&apos;m going to like it.&lt;p&gt;Nil pointers are #1 on that list. Tony Hoare called them a &quot;billion dollar mistake&quot;[1]. In Go, as in C, C++, or Java, any pointer can be `nil` (similar to `NULL`) at any point in time. You essentially always have to check; you&apos;re constantly just one pointer dereference away from blowing up the program. Since ways of solving this problem are known, I find this hard to swallow in a new language.&lt;p&gt;Compare Rust where, unless you have explicitly used the unsafe features of the language, all pointers are guaranteed non-nil and valid. Instead of a function returning a nil pointer, it returns an `Option` type which is either `Some ptr` or `None`. The type system guarantees you have considered both possibilities so there&apos;s no such thing as a runtime null pointer dereference. Scala has a similar `Option` type, as does Haskell, calling it `Maybe`. In 2013 I don&apos;t want to still constantly check for a nil pointer, or have my program blow up at runtime if I forget.&lt;p&gt;The second disappointment is that when I looked into it, it seemed there are ways to call C functions from Go code, but no working way to call Go from C code. Maybe that wasn&apos;t a goal at Google, but it seems like a missed opportunity. As a result, you can&apos;t use Go to write an Nginx module, or an audio plugin for a C/C++ host app, or a library that can be used from multiple languages.&lt;p&gt;I think there is a real unmet need for a higher-level, safer language you can use to write libraries. Imagine if zlib, or libpng, or the reference implementations of codecs (Vorbis, Opus, VP8) could be written in something like Go. Or spelling correction libraries. Currently we have two tiers of libraries: those written in C/C++, which can be used from any language under the sun (Python bindings, Ruby bindings, Perl bindings, PHP bindings...), and those written in high-level dynamic languages (Python, Ruby, Perl, PHP, ...) which can &lt;i&gt;only&lt;/i&gt; be used by the same language. We need a middle ground. C isn&apos;t expressive or safe enough to deserve to be the lingua franca like this. And Go is tantalizingly close to replacing it, but not quite.&lt;p&gt;[1]: &lt;a href=&quot;http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake&quot; rel=&quot;nofollow&quot;&gt;http://qconlondon.com/london-2009/presentation/Null+Referenc...&lt;/a&gt;</text></comment>
<story><title>Why I Like Go</title><url>https://gist.github.com/freeformz/4746274</url></story><parent_chain></parent_chain><comment><author>rogerbinns</author><text>I&apos;m still of the opinion go messed up the error handling badly.  As a simple example note how every tutorial doesn&apos;t bother looking for the error return of println calls and hence would silently ignore errors.&lt;p&gt;IMHO the ideal solution is that if you make no effort to look at the error return of a function, it is automatically returned to your parent.  This is somewhat analogous to exceptions, but they require a lot more syntax.  (Yes I know about panic/recover.)</text></comment>