To keep with the simplicity that I was aiming, I wanted a binary. I considered Rust, Haskell or Go (Swift was not opensource yet at the time) but went with Go because the libs that I will need (cron like scheduler, embedding assets, etc).
I had never written something in Go before but if I've known go then maybe I would have pick an other language as I started this project with a learning motivation.
I suppose he's referring to embedding files (usually web resources such as js, css files) into the source code, using a tool such as go-bindata [1]. The assets are then accessed as variables.
From a deployment standpoint, having a tool written in Go is a win for me since it is much simpler to get running than something in python or ruby which almost certainly has a larger dependency tree.
> From a deployment standpoint, having a tool written in Go is a win for me.
Deploying Go apps is not always easy from my experience(cross compiling for Android ARM). You need to cross compile Go source code for the target platform and it's not as simple as you hear from Go's tutorials on the internet. Most of them only demonstrate how to cross compile a small simple Hello World application. For actual app, you have dependencies from third parties and it's not always easy to cross compile with those deps especially when they rely on low level APIs(cgo).
For Java/C#/Ruby/Python/Perl/Javascript etc which constitute huge amount of business related apps development it is new and convenient deployment strategy .
As of the (now quite old) 4.2 release of gcj, static linkking is quite simple (as opposed to before, when it seems like it was possible but somehow frustrating).
Do you hate "written in Go" specifically? 'cause if you search for "written in" you'll find plenty of Rust, JavaScript, Python, and insert-language-here articles.
