Get Your Development Team Started With Go

Go Lang was a huge win for us in our server infrastructure. All high performant but hard to maintain C stuff got migrated to Go in 6 months and we never looked back. Code is much more managable, less debugging for memory management, much more readable and shorter by 60%. All that at negligable performance penalties.<p>For us its a freaking story of awesome success. Go = ROCKS!

People have been poopoo-ing Go lately on HN but let me tell you after using it in production for over a year. It really makes developers life easier. Why?<p>1) Error handling, Give you ability to impose defensive practices making network or another other I&#x2F;O failures or unexpected responses from external or internal calls easy to handle.<p>2) A lot of errors can be caught at compile time. Which means less errors in runtime.<p>3) It so simple that all of the build in functions and syntax can be expressed in less than 16 lines. Makes reading your code and anyone else code very very easy. Also FMT is sick.<p>4) Dead simple concurrency.<p>But all this has still not helped me push Go as the goto lang at the company I work for, why? Sometimes you work with people that just don&#x27;t want any change.<p>Give Go a try you&#x27;ll be shocked how well its designed.

Good article!<p>HN&#x27;s reaction to Go reminds me of Stroustrup quote about C++:<p>...&quot;There are only two kinds of languages: the ones people complain about and the ones nobody uses&quot;<p>So much complaining about how Go lacks this and that features of shiny new (and sometimes unfinished) language X. In the meantime, as time goes by it seems that more and more real companies use Go code in real production and are quite happy with it, despite all the shortcomings frequently listed here.

I setup my vim according to plugins described here[1] and go development has been a breeze ever since.<p>1. <a href="http://0value.com/my-Go-centric-Vim-setup" rel="nofollow">http:&#x2F;&#x2F;0value.com&#x2F;my-Go-centric-Vim-setup</a>

I think the bit on managing dependencies could be improved with a bit more information about what other people have done. For example, SoundCloud maintains one monolithic $GOPATH in a single git repository that they can then selectively update. My personal preference to any flavor of the month Go dependency managers is gopkg.in[0], because it doesn&#x27;t fool with the official tool chain (i.e. &quot;go get&quot;, &quot;go build&quot;), but still allows for the versioning of packages.<p>[0] <a href="http://labix.org/gopkg.in" rel="nofollow">http:&#x2F;&#x2F;labix.org&#x2F;gopkg.in</a>

The problem with Go is that it wasn&#x27;t designed to implement any large projects like C was. So the designers would typically make trade offs on perceived beauty and elegance rather than utility and potential pain in the real world. Another side effect of this is optimizing for compiler simplicity rather than optimizing for expressiveness of the language. It&#x27;s easy to forget we build compilers not for compiler&#x27;s sake but for its target user. Here&#x27;s the quote from Go&#x27;s history:<p><i>we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.</i><p>I would also argue C++ started in similar fashion but it went exact opposite route. The balance between minimalism and feature creep can only be achieved if you are designing language as a side effect of building your own large scale project combined with a sense of urgency.<p>Go is currently a lucky language. There is a huge vacuum that Java has left after Oracle acquisition plus its prolonged stagnation. People who need compiled languages for their relatively new code base, Go would end up becoming their choice regardless of its shortcomings. People will enjoy its minimalism until code base grows to be monster and features starts becoming sorely missed. This is nothing unusual in world of programming languages. We have seen COBOL become a gold standard at one point and PHP is still pretty hot.

Pretty good article on some of the challenges of getting started with Go. Certainly the package management issues point to Go&#x27;s youth.<p>I would have loved a more detailed explanation of why they chose Go for a particular problem space rather than C&#x2F;C++&#x2F;etc. What problems is Go particularly good for, and for which problems is it a poor choice?

I considered both Go and Dart for my new web projects - but as a former C# dev I&#x27;m too lazy to live without IDE (debugger intellisense etc) and ended up with Dart. Would love to see more tooling for Go to make it appealing for &#x27;VisualStudio like devs&#x27;

I&#x27;m using DO to hack together some web pages to help me verify data for my mobile app. I&#x27;m thinking about building out the pages. However, at the moment I&#x27;m using a simple shell script to start.<p>#!&#x2F;bin&#x2F;sh<p>export PORT=8080 go run go&#x2F;spanishdb.go go&#x2F;Html.go<p>Any good blogs on using Go in a production ready server? Should I run behind Apache?

I recently documented [1] my efforts to get a great experience with VIM and Go. It uses vim-go of course, but also supports tags and neocomplete.<p>[1] <a href="https://gist.github.com/cridenour/74e7635275331d5afa6b" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;cridenour&#x2F;74e7635275331d5afa6b</a>