Ask HN: Did you have second thoughts about Go from a business perspective?
For a project I am working on, I have found Go (golang) to be an ideal match for my requirements from a technical perspective.
However, up until now I have been very conservative in my tool choices. I typically chose Python, Java or C. Long-term vision, stability and support are important to me.
I know that Go has found an active community and several well-funded companies are betting on it. What I cannot estimate is how well things would work out for Go, if Google withdrew its love.
I assume none of you has a magic crystal ball, but did you have similar thoughts when choosing Go? How did you rationalise your choice?
Thanks for your thoughts
14 comments
[ 3.9 ms ] story [ 49.9 ms ] threadAs long as it increases developer happiness; I'm game with whatever language. :D
The NY Times open sourced a very cool tool "streamtools" that was built in Go: https://source.opennews.org/en-US/articles/introducing-strea...
Your question also reminds me of an interesting talk I saw at RICON: https://speakerdeck.com/al3x/nobody-ever-got-fired-for-picki...
Speaking of companies besides Google using Go: While I am aware that several companies use Go I am not sure if, worse-come-to-worst, one or several of them would invest in it if Google drops it. I would assume their thought process going something like: Should we invest to keep the language going or should we just let our Go apps run for now and rebuild them in something else? Or even worse, several dialects start popping up.
I hope I do not sound too negative, quite on the contrary I really like Go and most probably will go with it for a medium-sized project. It's just that I am still having an inner dialogue between the geek in me and channeling a very conservative pointy-haired boss :)
I have no quarrel with Java but Go's lightweight concurrency and design appeal to the minimalist in me.
Maybe I am just overanxious. What I will do now is to implement separate parts of my technical architecture in Go while taking care that I can cut any of them out, if required.
The dependencies that you need to avoid are runtime dependencies, the kind that can disappear overnight. Does my deployment depend on Rubygems or NPM being up? Did I accidentally build in a hard requirement for Google App Engine? Did I use a licensed piece of software whose license could be withdrawn overnight? Is there only one person who can even read my fancy-pants source code, and might that person suddenly decide to become a guru and retire to a distant mountaintop with no cellular access?
But there's no sense in fretting about what might happen on a five-to-ten-year timeframe. Face it: In ten years, the code you write today will look old. Using Java won't save you. The fact that Android is based on Java doesn't mean that ten-year-old Java apps support Android in any meaningful sense. Ten-year-old Objective C code is stale: It doesn't support iOS, it doesn't use new features of Mac OS. How do you even know which Python will be most popular in production in five years, Python 2 or Python 3?
Your code will evolve over the next N years, and if Go spontaneously implodes -- a very unlikely event at this point -- you'll do what the Docker folks are going to do: Keep using it for months or years while you port it to whatever comes next.
I'm not saying that makes C a reasonable choice. C is durable in the same sense that period costume films tend to age well.
I'm also not sure this is a counterexample. It's just the opposite perspective. From the perspective of a parent, a three-year-old becomes a thirteen-year-old with terrifying speed. A cell biologist would note that both kids are built from the same parts, many of which are also shared with killer whales and the front lawn.
My examples are all easy to flip in this way. The most remarkable feature of iOS is that it is directly descended from the twenty-five-year-old Next system, to the point that it carries all those cute little "ns"es around.
Change is constant, but provided one escapes the traps of lock-in (oops, Adobe Flash, dang!) and resists the whims of fashion, the change can happen slowly and piecemeal. If a new Golang library is important enough, it can always be ported to C later for the benefit of one's great-grandchildren.
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.
I saved about $1000 a month switching from Ruby to Go by refactoring a backend system. I was able to clearly demonstrate the reduction in resources and the switch was seamless.
Hard to argue against that.