This may be of interest https://www.computer.org/csdl/proceedings/hicss/2001/0981/05/09815015.pdf
> On Oct 13, 2018, at 12:18 PM, alanfo <alan.f...@gmail.com> wrote: > > 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 <>> wrote: > On Wed, Oct 10, 2018 at 7:55 AM, Beoran <beo...@gmail.com <>> 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 <>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > -- > Michael T. Jones > michae...@gmail.com <> > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.