I understand very well what the risks of standardization can be. Look at how the C language was maimed during standardization by 104 instances of undefined behavior.
But that is not what I am getting at. Five years ago I was somewhat involved in the effort to make Ruby an ISO standard language. From the get go it was a largely bureaucratic effort. We specified a common sub set of a then already old version of Ruby and made enough loopholes to make sure that any Ruby out there could be considered confirming to the standard. Why? You can perhaps not appreciate how powerful the bureaucrats can be in some countries and corporations. Since Ruby became an ISO standard, I have been able to convince those bureaucrats to let me use Ruby where I was barred from doing so before. For Go language it is now the same. Bureaucrats don't know Go, and because it is not standardized, I often encounter a "no go". A Ruby style standard that would allow developers to check the "ISO standard language" box would allow us to convince those bureaucrats to let us use Go much more widely. Like Michael Jones suggest, we would only standardize Go as it is, and not use the standardization process to let it decide the language features. And only update the standard once the new features are settled. That avoids design by committee as well. For these reasons I think, when done properly, the effort will be worth while in the end. Kind Regards, B. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
