Get Programming with Go is a beginner's guide to the Go programming language containing 32 quick lessons with plenty of fun exercises and silly gopher illustrations.
It's now available in print, and my publisher has made it the deal of the day today (September 19th, 2018). Get half off the ebook and print versions, with international shipping available.
The only problem is that you need to maintain and enhance that MVP for the next several years -- unless it's just a hackathon.
I've spent way too much of my life trying to optimize Ruby performance and memory usage, switching from one web server to the next, then fixing threading issues in dependencies, and so on. It's not fun. All that upfront productivity is lost in the end.
Quite happy to spend more time upfront investing in a reliable end-product.
There was also the matter of figuring out llvm in order to use it. The initial Go compiler was based on the Plan 9 C compiler toolchain, which the designers of Go know well.
One of the other reasons relates to how stacks are handled for goroutines.
There are active discussions on the Go Package Management mailing list and the intention to propose further improvements to the go toolchain for future releases. We had good discussions with the Go Team during GopherCon last month.
This article is an excerpt from Learn Go, a beginner's guide to Go, that I am writing with Manning Publications.
I'm targeting people with some experience with a scripting language but fairly new to programming, while trying to keep it moving at a good pace. If that describes you, I'm very curious if it makes sense or what areas should be better explained.
If you are new to Go and statically compiled languages in general, I've been working on a book to introduce you to Go.
The first two chapters are now available through Manning. Use mlyoungman to receive 50% off through October 17, 2015. This affiliate link earns me a few extra %. Thanks.
I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go?
- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.
- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.
Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(
- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.
- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.
I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)