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