The purpose of a standard, in my opinion, is to allow multiple implementations to be compatible. This seems counter to the open-source model, where there is a reference implementation completely in the open that encourages community participation and improvement.
JavaScript needs a standard - there are many implementations and browsers. For the moment, there is only one Go, and I like that. Mike On Wednesday, October 17, 2018 at 11:41:36 AM UTC-4, Scott Cotton wrote: > > I think standards have a tendency to end up failing to be standard because > of a plethora of standards, the need to make optional parts which render > the standard impractical for basic tasks (eg open al), the fact that large > market interests tend to have their own version (eg open SL ES android), > etc. > > Small teams can make inspiring designs, such as Go. > > That said, Go lacks standardisation of the memory model and runtime. > These render the qualitative semantic of the language unspecified. To > date, in my opinion, this is a good thing because it has allowed decision > to evolve and be driven by use. > > However, I think now many of us would welcome steps towards specifications > of the memory model and runtime. Full specifications would require a lot > of diverse expertise, coordination, and effort. > > If enough people are interested in contributing to that, maybe a SIG or > two would provide an opportunity for small yet diverse teams to start to > make progress, maybe incrementally specifying these things over time rather > than a formal standards committee imposing full specifications would be > more practical. I would be interested in following that. > > > On Wednesday, 10 October 2018 18:48:57 UTC+2, 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
