Most medical research already happens in publicly-funded bodies, bit it is then spun-off and captured by big pharma.
Not to mention that as many have pointed out over and over again, the main expenses of drug companies are not research, but drug approval bureaucracy and marketing.
If you hire a Go programmer, it probably will be somebody that deeply cares about their work, somebody who has a certain sense for aesthetic and technical simplicity, and other qualities that not common that among Java programmers.
Many people are not looking for a "better C++", in the land of C++ it seems "better" means "more features", and some of us are not interested in more features, but in a better selection of fewer useful features.
See Rob Pike's essay on this very topic and the design of Go:
> This seems like needless boilerplate: why not instead simply pass a closure over a channel that the goroutine will execute? I have never seen this technique used in Go, but it seems natural to me. (It's essentially how libdispatch works.)
Passing a closure on a channel is both idiomatic and relatively common in Go code.
This and other comments make me suspect the author could have benefited from spending more time looking at existing Go codebases (the source of the Go stdlib is excellent).
Edit: His (IMHO somewhat strange) complaint that "Channel reads violate the laws of time and space by changing their behavior based on how their return values get used." doesn't apply anymore, now to do async reads from a channel you use select with a default, not the comma-ok idiom.
Also a package including more 'clever' Unicode operations will also be part of Go 1.1, but I have personally never found the existing support lacking, and no, I don't live in an English speaking country.
Sane and simple standards that can be implemented in any platform without requiring hundreds of man years of effort.
Nothing done in the web today is particularly technically advanced, we are about the same UI level as standard apps were more than 10 years ago (hell, I doubt you can build a photo manipulation app today that can compete with where Photoshop was 10 years ago).
Most of the complexity burden the web has is purely gratuitous and product of how flawed the standards it is built on are.
How JSON replaced XML is a good illustration of what is the right direction to go. Now if for example JavaScript was replaced with something considerably simpler, like, say, Scheme, instead of trying to bolt even more OO-crud into it and turn it into another pseudo-Java, that would be another good step.
There is little doubt the DOM and CSS could be dramatically simplified without reducing functionality, same goes for HTTP (as a recent post to hacker news illustrated).
The Web 2.0 craze is leading us back to the "Best viewed with" insanity of the 90's.
And is only going to get worse, with WebGL is not just "Sorry your browser is not supported, please download a different one.", but "Your video card drivers are not supported, buy new hardware and/or install a different Operating System"
Because one of the nice things about Go is that I don't have to worry about this.
Is not just unidiomatic code in itself, but it creates unidiomatic APIs that behave in ways Go programmers don't usually have to worry about.
Unlike Python programmers, who should always be worrying about what exceptions any function or method they call could throw, hell, even setting a property or adding an item to a map or list can throw all kinds of exceptions. And this is rarely documented, and when it is documented it is usually incomplete, because whoever wrote that code doesn't know what exceptions might be thrown by any other code he calls.
Panic() should only be used to signal either programmer error, or truly panic-worthy situations where state is so messed up that crashing is the only good option.
Put another way: when you call an API correctly, it should be safe to assume it will never panic().
Panic/recover can be used in rare occasions within libraries to do more exception-ish style error handling, but those panics should never be allowed to escape and cross API boundaries.
Anyone using panic/recover across API boundaries to emulate exceptions should have their brains gofmt-d.
But so far I have not noticed anyone doing this, perhaps because actually returning and handling errors properly is not as much of an issue as most people make it to be.