Ask HN: Did you have second thoughts about Go from a business perspective? | Hacker News Reader

Ask HN: Did you have second thoughts about Go from a business perspective?

8 pointsrsto14 comments

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

View on HN

What are you afraid of? Go is compiled. You have the compiler. You have the libraries. You have your code. You have perpetual licenses to run these things, and even to fork them. Construct yourself a solid build chain, the kind that works even when you unplug it from the network. Bundle it inside a virtual machine, and it'll probably still be runnable in two decades.

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.

Counterexample: C code from the late 1980s is routinely useful. Ex: I still use the timer code from MIT Athena.

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.

You may notice that I carefully elided C to Objective C when selecting examples of things that change. :)

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 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.

I know of several startups in NYC using Go to great effect; bitly's nsq comes to mind: https://github.com/bitly/nsq

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...

Thanks for the link to the speaker deck slides. For anyone else interested, here is the link to the video recording: http://www.youtube.com/watch?v=0zJIqdw19N8

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 :)

Started out with a small project; even a rewrite in a different language would not matter that much (a 40 hrs writeoff or something).

As long as it increases developer happiness; I'm game with whatever language. :D

I don't see how any business except Google could rationalize using it. Maybe if a company hopes to someday be acquired by Google they might use it to impress some Google execs. Even if it could rapidly evolve, which it probably wont being an ivory tower project, Google won't put the same resources behind it that Microsoft did with visual studio, .net, and c#. It will become what Objective c is to developers, an annoying language they occasionally have to deal with.

No "Google exec" cares whether you build your service in Golang or Python.

I'm positive many would be swayed a tiny bit by the phrase "the company is very google-centric, they even use Go." Consider the career exec that came from another industry or segment who has never done anything technical.

I'm positive in the exact opposite direction, so we're at an impasse.

What are you gonna use it for? Go seems to have a strong foothold in cloud-related projects (i.e. Docker, Flynn, many parts of CoreOS). So if you're in the same niche it's probably an okay choice even if only for community reasons. But if you're doing something app-level you're probably taking a big risk.

A networking server with a web app to manage it. Performance is relevant but not critical enough to warrant C or C++. While I like Python I would prefer a static type system for this project. So it is basically Java vs Go.

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.

Here's how I did it and it'll sound like a geico commerical:

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.

Reply on news.ycombinator.com