May I remind those who are in favor of Go standardization that Java and Python have never been standardized by ISO/ANSI/ECMA but that hasn't prevented them from becoming extremely successful languages.
I find it hard to believe that there are large organizations in this day and age who eschew the use of these languages solely because they're not standardized. Their reference implementations are in effect 'de facto' standards and I don't see why Go, which has a complete and very clear specification, can't become the same. Alan On Wednesday, October 10, 2018 at 5:48:57 PM UTC+1, Michael Jones wrote: > > I was the engineering director for OpenGL’s birth and growth at SGI and > have perspective on that process, and was for a long time a board member of > the Open Geospatial Consortium (OGC) and have views from those ISO-related > adventures. > > I’m with Ian on this—I quite deeply respect standards but see them best as > “recognition of standard practice” rather than “political arena to fight > out new ideas.” The political aspect is not evil, it is simply > acknowledgement of the need to respect diverse stakeholders; but what is > bad about it, technically, is that the path finding of a small inspired > team easily gets lost in the chorus of multitudes wanting everything. > > In UNIX you had a small inspired team. In almost every really great, > lasting technology you have <= 20 people, often <= 2, who are making the > contentious decisions. That is a critical number. The smallness allows a > cohesive thought process, which allows spirit and flow. Big groupthink > tends the other way, often with better individual decisions but with ideas > that seem almost randomly distributed across the design space. > > I would vote to standardize Go 1 when Go 2 is out. > > On Wed, Oct 10, 2018 at 8:16 AM Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >> On Wed, Oct 10, 2018 at 7:55 AM, Beoran <beo...@gmail.com <javascript:>> >> wrote: >> > >> > In certain environments, such as for government contracting in certain >> countries, or for certain large corporations, or for developing safety >> critical applications using certain international standards, only >> programming languages that are officially standardized may be used. While >> Go would be an excellent language for such government or safety critical >> applications, it's acceptance is hampered due to the lack of an official >> standard. >> > >> > While this is in essence a formality, which would entail submitting the >> current Go language specification with the ANSI, and then have it propagate >> to the ISO, I do appreciate that will take quite some time and effort. But >> to further the acceptance of Go language, I would propose that Google >> invests the necessary resources to make this happen, with support from the >> community to edit the standard document if needed. >> > >> > The standard should probably be based on Go 1, since Go 2 is still >> largely undecided and probably 5 years in the future. >> > >> > If you are worried about using Go for safety critical applications >> consider this: it is rare that the compiler builder gives any safety >> warranty, although there are some safety certified C compilers. But for >> similar certified Go compilers to be developed, we need an official >> standard first. >> > >> > Even if the compiler is not certified, you can still use it if you >> validate it yourself. This implementation of go has extensive unit tests >> which simplifies such validation a lot. >> > >> > I know of some safety critical software that is implemented in C and >> compiled with GCC. As a language, Go is far safer than that, and that is >> also why we need a standard, to be able to get away from C for some safety >> applications. >> >> There are significant disadvantages to the standardization process. >> >> It is slow. >> >> It is easily politicized, with the possibility that changes to the >> language twill be determined by those with the patience and >> wherewithal to work through the standardization process, rather than >> those with a clear understanding of how the language will work best. >> This is not an inevitable result, but it is a risk. >> >> A likely approach to Go 2 is to roll out changes over time through a >> series of releases. That would be inhibited by a standardization >> process. >> >> The advantages that you describe for standardization are essentially >> bureaucratic: some organizations require a certain approach, not >> because it is clearly better in all cases, but because that it their >> preferred process. They could choose to change their requirements, >> with no affect on Go. Meeting their requirements will inevitably have >> an effect on Go. >> >> I note that C was standardized nearly 20 years after it was developed, >> and C++ took about 16 years. In both cases there were multiple >> implementations from different organizations, so there were additional >> benefits to standardization. Go is not yet ten years old, and there >> are not as yet significant competing implementations. >> >> At this stage of the lifetime of the programming language, I think >> that the disadvantages outweigh the benefits. >> >> Ian >> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *Michael T. jonesmichae...@gmail.com <javascript:>* > -- 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.
