"But he didn't touch the important question -- is the development time for Go faster than for scripting languages + C?"
That is a good question, but- Isn't that going to vary a lot by the person/team involved? Calculating "effort" is far more difficult than run-time or complexity characteristics.
Doesn't that question also assume that people writing in the scripting language can write (correct/decent/secure) C. Ironically, I have a strong feeling that many more Go developers can write C than say Ruby or PHP devs.
"If it really was impossible to measure development/support speed, then we'd still use hex code with switches on a console. :-)"
Of course it can be quantified. Some people use gzipped source code size to approximate this. I just meant that this is more subjective, has more variables and sometimes must be decided per organization or team.
"And yeah, kids today often don't learn C at school, it is a pity."
Most C-S programs I have interacted with still teach C, but yes that is a problem. I was more thinking of the "too cool for school" portion of the startup crowd, those who learn only learn scripting languages, etc
I would say "kids today often don't learn about compiler design and computer language's history".
Given my CS background, it baffles me how languages get mixed with implementations or language runtimes with VMs in current discussions.
I started coding in the mid-80s, we lacked the information access kids have nowadays with Internet, and yet most of us were quite aware what language design was all about.
That is a good question, but- Isn't that going to vary a lot by the person/team involved? Calculating "effort" is far more difficult than run-time or complexity characteristics.
Doesn't that question also assume that people writing in the scripting language can write (correct/decent/secure) C. Ironically, I have a strong feeling that many more Go developers can write C than say Ruby or PHP devs.