Thanks for posting that very interesting link, Robert. I'd remembered that Sun originally attempted to standardize Java in the late 1990s but later withdrew it. However, I didn't know their reasons for this until now.
Alan On Saturday, October 13, 2018 at 7:10:42 PM UTC+1, robert engels wrote: > > 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...@gmail.com <javascript:>> > 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. >>> >> -- >> >> *Michael T. jonesmichae...@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...@googlegroups.com <javascript:>. > For more options, visit 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.
