Hacker News Reader

Comment by larsberg | Hacker News Reader

It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers.

It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compiler writer myself (albeit a research compiler, Manticore), ownership dramatically changes your attitude towards using a language. Optimization limitations become "small bugs to fix when you run into them" rather than a "reject this tool as unusable" issue.

View on HN

There's lots of companies using Go for serious work these days. It's not just Google.

Also, Go is an open source project. A company that cared could make their own internal folk and modify it as much as they want.

There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go:

http://go-lang.cat-v.org/organizations-using-go

Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.

I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewrite?

Hopefully we'd never rewrite Haskell - there's enough people here that know it and Haskell is extremely easy to understand.

The team rewrote from Go to Python for various reasons:

* Tool support (debugging, etc) was supposedly poor

* The standard library wrappers were supposedly buggy

* They had to write a lot of wrappers and libraries themselves

* People on the team were already familiar with Python - after Atlassian's single "Go developer" left, there wasn't much reason to keep it

Not blaming you, since there were people familiar with Python, it's probably good thing to continue using it.

Just thought I'd point out to people that this rewrite was done "last year", which was before Go1 was released march this year. The API was in constant change and it all projects needed constant updating to keep up with weekly releases. (or stick with the r60 with totally different and soon-to-be deprecated API)

API is frozen now and life is good.

> Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety.

I think it's very naive to think that the value of a language in a corporation is limited to its syntax or compilation speed.

Not just compilation (which is apple-to-oranges since python is bytecode-compiled and then interpreted/JIT compiled), but also execution speed, which means that you need less hardware to do the same job. That's definitely worth something in some cases.

If I had limited my analysis to just those things you would have a point. I didn't though. errnoh provided the justification OP was missing. The pre Go1 api changes where a very fast moving target so reducing that maintenance burden was a valid concern. My response was just consternation at the desire to rewrite something when the language is simultaneously easy to learn, safer to modify, and probably faster and more efficient at the task than the language you rewrote it to.

Certainly. But turn that around --- if all of the major Go developers were at Canonical, even if it were precisely the same language today, would Rob and Google use it?

The Go developers (with, perhaps, the exception of ken - but he's a pretty special guy) have all worked in languages that they didn't design or write the compilers for, so I'm not sure what you're getting at.

Startups have bet their business to any random language, from PHP to Dylan.

It's AFTER the startup phase that you rewrite your messy infrastructure (see Twitter, Facebook, etc), and that's when you need mature and capable tools.

Reply on news.ycombinator.com