Why Go is elegant and makes my code elegant

I think elegant is probably the wrong word. Practical is the one I would use. Go isn't Haskell; it isn't there to impress the PL guys. They boiled down the average imperative language and made many decisions for you so that opinions don't have to collide while working on a project. Because the decisions they made, they have very nice tooling to go along with the language.

Some of the pain points I&#x27;ve seen:<p>* while &quot;go get&quot; is nice, it doesn&#x27;t handle version pinning at all. So for a large team working on a go program, you need another solution. Luckily there are tools like godep[0] that will allow version pinning and putting it&#x27;s source code into your projects root.<p>* debuggers (gdb) are only partially supported. Most people don&#x27;t have problems with this, but occasionally it&#x27;s an issue.<p>* Windows support is not as strong as Linux and OSX. But it still works surprisingly well.<p>[0] <a href="https://github.com/tools/godep" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tools&#x2F;godep</a>

This may be an unpopular opinion, but I hope Go is relegated to web services programming. It&#x27;s really not a good language for much else. The lack of generic support is really terrible. What you have to do instead (cast things to {}interface) is like casting things to Object and then hoping they have the right methods in Java.<p>For everything else, I think Rust is miles better than Go. It stole a ton of useful features from Haskell&#x2F;ML and did a great job of putting them together. I actually <i>want</i> to use Rust instead of C++, whereas the only reason I ever really want to use Go is that its decent threading primitives and good standard library make for simpler web apps.

OP has never heard of panic() and recover(), which are awful things that should not exist.<p>I&#x27;ll speculate that he hasn&#x27;t used a language with a usable sum type either, because I&#x27;d expect people who have been exposed to this would take issue with the idea of expanding every 5 line method to 40 lines of mostly error handling.

I love go, and I concur with almost everything the author wrote here. A small pain point in my experience though is that Go lacks an elegant way to pass type information around without using a zero valued (or fully populated, it makes no difference) instance. For example, I have a factory struct with a New &#x27;method&#x27; that returns interface{MySignatures()}, but I cannot inform the factory of the concrete type I want it to produce without passing in something like new(ConcreteStructWithMySignatures). Some have suggested I pass in a string, but what is the point of a type system if I have to use strings to reason about my types?

It&#x27;s elegant right up until you need generics. Then it gets ugly fast.

Having uniquely-named packages is insufficient unless the maintainers of those packages never update them. The point of tools like Bundler is not about name resolution, it&#x27;s about VERSION resolution.<p>Sample size of 1, but here&#x27;s a story about what happens when things go wrong:<p><a href="https://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre/posts" rel="nofollow">https:&#x2F;&#x2F;www.kickstarter.com&#x2F;projects&#x2F;2066438441&#x2F;haunts-the-m...</a><p>The bit about packages from github.com being edited <i>locally</i> was particularly hair-raising. Really hope the smart folks working on Go figure out a resolution for this kind of thing.

The Author touches on a lot of nice points, but does not address some of the problems with using Go.<p>Anecdotally, from using Go for a number of projects... As a rough approximation, I think Go&#x27;s marginal return tops out at about 1000 lines of code. Past that point, syntactically it is hard to do abstraction (interfaces or generics).<p>As a result, I use it for scripting but not for larger projects.<p>What about you all?

Go exception handling (or lack thereof) sucks. Things can just blow up silently at runtime unless you check the error code return of practically every statement.

Has the popularity of Go died off recently?<p>This is the first Go article I&#x27;ve seen on the front page in a while...

&gt; If you write a package, it will have a name. A unique one. In all the universe.<p>How does that work?

Why the strong opinions about blocking? Go discourages, at least me, from doing non-blocking IO. I&#x27;ve heard that&#x27;s a unix philosophy though. For example, io.Copy will block.

&gt; Go is compiled. This has a number of advantages, first being all the errors that can be detected by the compiler<p>You can have static typing and type checking without compilation. The interpreter can just complain to you when you try to run it.

one mans trash anothers treasure. When I pointed out that Django is an annoying framework because it breaks up your ability to prototype flat by forcing you into some workflow structure I was told &quot;that&#x27;s a feature&quot;. Go is similar. It&#x27;s annoying but some people like bumps in the road. Enjoy

interesting..