I like Golang and have used it on two commercial projects.
I've also gotten to work with tens of companies that use Golang for things internally (we consult for software security).
My advice is: Golang is great, but use it like most established companies do: for smaller and/or specialized backend components.
What I might not recommend is doing a soup-to-nuts SAAS application entirely in Golang. We use Rails as our frontend for Microcorruption.com, and Golang to do the heavy lifting of emulating thousands of microcontrollers.
Sticking with something convention for your front-end solves a couple problems:
* Golang's front-end capabilities aren't as mature as Ruby's and Python's. You can find yourself fighting the libraries a bit. In particular: you'll end up writing a lot of boilerplate database code.
* There is a much broader base of talent for building Rails and Python than there is for Golang. And: most teams have people that specialize on front-end and (a usually smaller) group of people that do the hard-core backend stuff.
* Backend components are usually architecturally hidden, which should give you some peace of mind about ever needing to replace those Golang components --- you might never need to do it if you draw the right boxes and arrows, and if you do, at least you'll be replacing a well-defined component.
Comments
I like Golang and have used it on two commercial projects.
I've also gotten to work with tens of companies that use Golang for things internally (we consult for software security).
My advice is: Golang is great, but use it like most established companies do: for smaller and/or specialized backend components.
What I might not recommend is doing a soup-to-nuts SAAS application entirely in Golang. We use Rails as our frontend for Microcorruption.com, and Golang to do the heavy lifting of emulating thousands of microcontrollers.
Sticking with something convention for your front-end solves a couple problems:
* Golang's front-end capabilities aren't as mature as Ruby's and Python's. You can find yourself fighting the libraries a bit. In particular: you'll end up writing a lot of boilerplate database code.
* There is a much broader base of talent for building Rails and Python than there is for Golang. And: most teams have people that specialize on front-end and (a usually smaller) group of people that do the hard-core backend stuff.
* Backend components are usually architecturally hidden, which should give you some peace of mind about ever needing to replace those Golang components --- you might never need to do it if you draw the right boxes and arrows, and if you do, at least you'll be replacing a well-defined component.