> Randomize some CS students into Go and non-Go and see which teams produce projects with lower rates of defect and faster time to submission. Using students s

> Randomize some CS students into Go and non-Go and see which teams produce projects with lower rates of defect and faster time to submission. Using students still has problems - have they coded before? Have they worked in a team with industry-style review processes before? The population you're sampling is quite different to experienced software engineers. It's not quite "...in mice" levels of qualification needed, but it's fundamentally the same problem. > Try it with teams in enterprises; I'm 100% certain that this kind of statistical evidence is meaningful to some CTO/CIO somewhere Difficult again - how do you do a fair comparison? You'd need to be doing fair randomization - in particular as soon as anyone gets any say in which team uses what language for which project, you have a good chance of stuffing things up. Is one of the projects more important to the business, so is likely to get a "better" team allocated to it? Does one of the teams have a language preference? Does the business have a language preference? Is one of the projects well-suited for Go (say a web server) and the other terrible? (say a desktop app) One approach might be to get two teams to build the same thing and one gets thrown away, but what CTO is going to pay for that once? Let alone finding enough to pay for a big enough sample size to make anything of. I'm not trying to get into fights about languages, I'm trying to make the point that actually making an objective measurement like you suggest is really, really difficult.