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.

Reply via email to