I have occasionally seen code that assumed that signed ints roll over nicely to a negative value when they overflow, e.g. “if (i + 100 < i) ….". A good optimizing compiler will omit the comparison because signed overflow is undefined behavior. A better compiler will emit a warning about omitting the comparison. When last I checked gcc didn't.

Off topic, I saw code recently like 'if (foo() == "bar")' which passed tests because most compilers merge (some) manifest string constants. I would expect a good compiler to warn about this, and treat the expression as always false.

We’ve not enabled -Wsign-compare in coreutils at the moment, due to some ugliness that’s introduced in the code to work around the false positives. But it is a very useful warning to enable as I for one easily miss these. For a concrete example of a portability fix see:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e2dbcee4

Administrators of hospitals not using strict checklist procedures should be considered criminally negligent. That members of the medical profession are not spontaneously adopting these changes wholesale speaks volumes.

Maybe a collection of hypertrophied, er, “lights”, could be kept operational (not to say “healthy”) as muscle is grown and harvested and grown again. You would need clean-room conditions, as in chip fabs. I suppose the feedstock would be hydroponic algae, solar-pumped. Whatever mix of elements are taken away with the meat would need to be fed back to the algae. It is hard to imagine such an operation running as cheaply than what is done now.

Probably more effective (somebody wake up Freeman Dyson) would be to get trees to grow meat fruits. Maybe start with a jackfruit tree…

jyasskin: Channels are neither better nor worse than the threadpool I wrote. The difference is simply that since channels are built into the language, any concurrency issues only have to be fixed in one place. Gold had to be highly portable, and there is no standard concurrency library for C++. Even the libraries planned for C++0x are too low-level to really help people avoid concurrency problems; they just standardize and clarify the operations which programmers already use. (Of course portability also precludes writing gold in Go, at least at present; I was really just thinking of the advantage of including solid concurrency support in the language.)

kcc: I didn’t mean to impugn the tool, which you’ve done a great job on. By false positives I meant cases where different threads can initialize a variable simultaneously, but they always initialize the variable to the same value. This is (as far as I know) safe on popular hosts, though it is technically a race and can fail on some unusual processors.

But you’re definitely right about tsan. It’s amazing at finding races.

You do have some good arguments; if you are interested in changing the language, I recommend that you bring this to the golang-nuts mailing list. Nothing is going to happen based on a discussion here.