It has become the default Go-To (pun intended) language for me for almost anything that needs to be small and portable.
However, I don't see myself writing a full server with it, I would still prefer a dynamic language like Ruby/Python for that and use Go for micro-services CLIs and the rest.
Our main application is Rails, it communicates with SOLR as the search index, in between the application and SOLR there's a proxy server that backups the documents onto S3 and also does Round-Robin between slaves.
One other thing is that we use Go to communicate with all external APIs of 3rd parties, the application code is rails and it communicates transparently with a Go server that fetches the data from 3rd parties and responds to the main application.
It doesn't make Go a bad language,it has a some good percs, it's just frustrating that its authors conflated simplicity with rigidity. Also I hate when languages have hidden APIs, i.e. things the language can do that the programmer can't. Go is full of these (for instance append which is a parametric function since it knows the proper return type no matter what type of slice you pass it, but you can't write your own? ).
It's good think that it requires very little investment to get started, but it becomes highly frustrating when one stumbles on its limitations.
To me, the power of Go's simplicity is almost always underestimated by the language's detractors. I can look at code my team wrote two years ago and with a few <leader>gd's in Vim I know what's going on. Obviously Python fails this test, but even a high-level static typed language like C# can suffer greatly from all the magic one can invoke (Linq being a great example).
What it comes down to is that Go doesn't give you many ways to be clever. Younger me who loved template metaprogramming in C++ would scoff at this statement, but if you go back and have to reverse engineer your own cleverness enough times you really, really start to dislike the practice.
Python is in between, I can find myself pretty damn well in a big Python codebase after awhile but Ruby... Ruby is a pleasure to write first and get lost later, I've done too much of it to like, all of the metaprogramming is gonna come back and bite your mind chunk by chunk when the codebase gets big enough. Few times I've been more frustrated in my life than when debugging Ruby and thinking "where the hell is this function defined at?" to find out it was some sort of generator stuff spitting out code.
(C++ uniquely bites you at both ends :)
Finding out, with absolute certainty, which code calls which code under which circumstances is a life-saver.
Any modern IDE for JVM languages accomplishes that.
It's not enough for your code to be readable.
It needs to be statically traceable.
I completely agree with your overall point, but typically reflection will inhibit truly 'absolute' certainty.
All of my lambda functions are a thin Node wrapper on top of Go applications.
The go application is simply a command line accepting JSON via stdin (from the Node wrapper). It is a Joy to test, you can run it locally/independently etc...
[Edit]: Typos fix
It's simple enough to understand with absolutely no documentation. But here's the gist.
You develop in Go, you can run tests or run it independent from the lambda and then, when you want to deploy you run `release.sh`.
This is perfect for web callbacks, SNS notifications etc...
It's amazing how good they perform with minimal memory usage.
In this blog post the previous solution is presented using Nginx, now it's Golang similar to Templar (mentioned in the post).