Re: [go-nuts] Go language should become an ANSI and ISO standard.
> JavaScript needs a standard - there are many implementations and browsers. > For the moment, there is only one Go, and I like that. one go, but two reference implementation. any other implementation is expected to conscribe to the spec. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 >> wrote: >> >>> On Wed, Oct 10, 2018 at 7:55 AM, Beoran 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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 > wrote: > >> On Wed, Oct 10, 2018 at 7:55 AM, Beoran > >> 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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I don't whether establishing a community based workgroup would help Go to gain wider acceptance or not. Java has its JCP program and Python has PEP which seem to work in a fashion. However, I certainly think that this sort of approach would be preferable to formal standardization which I am completely opposed to. Alan On Saturday, October 13, 2018 at 10:51:46 PM UTC+1, Björn De Meyer wrote: > > I can assure you that my concern is not theoretical but based on real life > experience. Unfortunately I am not at liberty to discuss in detail... > > As for the approach, a community based workgroup with backing from Google > may be a more viable idea. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I can assure you that my concern is not theoretical but based on real life experience. Unfortunately I am not at liberty to discuss in detail... As for the approach, a community based workgroup with backing from Google may be a more viable idea. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I guess that would be a workaround, but a Go to, say , Ada transpiler is not an easy project. Still, something to consider. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
Java and python have become so common that all but the most hard headed bureaucrats have to acknowledge those languages, if only for the ease of hiring people who can program in them. The same cannot be said yet of Ruby and Go, which are far less popular. Hopefully that will change, but for the time being a standard would help. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I see, I did not realize that in the USA, the standardization organizations expect to take control over the language. That is not very good. I understand people's concerns better now. The Ruby standard was submitted through the Japanese standard organization which was far more sympathetic and flexible, and did not demand control at all. Since Google is multinational, I think we could "shop around" for the most sympathetic standardization organization. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 > > 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 >> wrote: >> >>> On Wed, Oct 10, 2018 at 7:55 AM, Beoran 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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 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 > wrote: > On Wed, Oct 10, 2018 at 7:55 AM, Beoran > 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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 > wrote: > >> On Wed, Oct 10, 2018 at 7:55 AM, Beoran > >> 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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
In my opinion, currently there is no need for Go 'standardization'. There aren't multiple implementation of Go where each vendor is eager to add their own features and promote their own version of Go. In fact, by giving up control to a committee (especially during this early stage of the language - Go is still version 1 and barely version 2), it risks the language development spiralling out of control, becoming the next C++. I say keep it as it is for the time being. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
On Fri, Oct 12, 2018 at 12:21 PM, Liam wrote: > > If there is already a member of the Go team doing outreach to government and > enterprise IT managers, it would be interesting to hear from them re > requirements they've heard from this category... That is a fair question. At present the concern expressed here seems to be hypothetical. Does anybody know of any real projects that would prefer to use Go but can't because there is no official international standard? 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
You may need to find a large organization with ISO-only policy to approach the Go team directly, and help staff a standardization effort. If there is already a member of the Go team doing outreach to government and enterprise IT managers, it would be interesting to hear from them re requirements they've heard from this category... On Wednesday, October 10, 2018 at 9:15:30 PM UTC-7, Beoran wrote: > > I understand very well what the risks of standardization can be. Look at > how the C language was maimed during standardization by 104 instances of > undefined behavior. > > But that is not what I am getting at. Five years ago I was somewhat > involved in the effort to make Ruby an ISO standard language. From the get > go it was a largely bureaucratic effort. We specified a common sub set of a > then already old version of Ruby and made enough loopholes to make sure > that any Ruby out there could be considered confirming to the standard. > > Why? You can perhaps not appreciate how powerful the bureaucrats can be in > some countries and corporations. Since Ruby became an ISO standard, I have > been able to convince those bureaucrats to let me use Ruby where I was > barred from doing so before. > > For Go language it is now the same. Bureaucrats don't know Go, and because > it is not standardized, I often encounter a "no go". A Ruby style standard > that would allow developers to check the "ISO standard language" box would > allow us to convince those bureaucrats to let us use Go much more widely. > > Like Michael Jones suggest, we would only standardize Go as it is, and not > use the standardization process to let it decide the language features. And > only update the standard once the new features are settled. That avoids > design by committee as well. > > For these reasons I think, when done properly, the effort will be worth > while in the end. > > Kind Regards, > > B. > -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
Is an alternate solution to use Go as a source language, then translate to an allegedly "ISO" language? Eric. On Thursday, October 11, 2018 at 8:57:39 PM UTC-7, Beoran wrote: > > So no matter if I say yes or no, both ways are bad? I think is not a very > fair way to argue. > > Anyway, with the Ruby standard you can do either. The Ruby standard > defines that there are strictly conforming Ruby processors, which implement > the standard and conforming Ruby processors which may have any number of > additional implementation defined extensions, alternate syntax and language > features. > > After the standard was written, mruby was implemented to be a strictly > conforming Ruby processor, which doesn't influence or hold back the > development of the other Ruby implementations at all. > > And all other Ruby implementations can be considered confirming, which is > worth millions of $$$ to Ruby developers. The organizations and governments > I mentioned tend to have deep pockets, and the Ruby standard enables us > to gain approval from said bureaucrats. So, we can now use Ruby for these > well funded projects, since now it is an international standard. > > So actually, because the Ruby standard was carefully written to enable > this, it has been win/win for Ruby developers. You can use a strictly > conforming mruby if you like or need to, or use any other Ruby > implementations as conforming ones and please the bureaucrats. > > I consider that we should do the same for Go. When done carefully it will > also be a win/win. > > -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
Paul, I fully agree with your ideas on what should be standardized. Either a subset of Go1 or Go1 once Go2 is in full swing. Go++, perish the thought! >_< -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
If Go is to be standardized, it needs to be as late as possible in the development of Go 1. My observations of being involved with some standards is that the participants view it as an opportunity to change or add to whatever is being standardized. Unless the standard was simply a true codification of the existing Go 1 language (e.g., the existing Go compiler is strictly conformant) I think it would do harm to the language. As others have mentioned, it would be best to do this once Go 1 pretty much stops being developed. We certainly don't want a standards organization to essentially define Go++. -Paul On 10/11/18, 10:58 PM, "golang-nuts@googlegroups.com on behalf of Beoran" wrote: So no matter if I say yes or no, both ways are bad? I think is not a very fair way to argue. Anyway, with the Ruby standard you can do either. The Ruby standard defines that there are strictly conforming Ruby processors, which implement the standard and conforming Ruby processors which may have any number of additional implementation defined extensions, alternate syntax and language features. After the standard was written, mruby was implemented to be a strictly conforming Ruby processor, which doesn't influence or hold back the development of the other Ruby implementations at all. And all other Ruby implementations can be considered confirming, which is worth millions of $$$ to Ruby developers. The organizations and governments I mentioned tend to have deep pockets, and the Ruby standard enables us to gain approval from said bureaucrats. So, we can now use Ruby for these well funded projects, since now it is an international standard. So actually, because the Ruby standard was carefully written to enable this, it has been win/win for Ruby developers. You can use a strictly conforming mruby if you like or need to, or use any other Ruby implementations as conforming ones and please the bureaucrats. I consider that we should do the same for Go. When done carefully it will also be a win/win. -- 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. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I would not call it deceit, since the Ruby standard does accurately describes a subset of Ruby v1.8. It is more a workaround for institutional rigidity. I guess we would likely be better of without such bureaucracies, but it is utopic to think they will disappear any time soon. The best we can do for now is to enable programmers to use of better programming tools such as Go in such environments. Paperwork is the only language understood there, and that is why a standard would help greatly. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I'm not sure whether this way lies madness or whether the madness is the starting point. In a world not corrupted by daily fake news and gratuitous displays of violence and human suffering and animal suffering for the sake of increased profits, the concept of performing some sleight of hand to fool bureaucrats into believing they are buying a "standard" where they are in fact facilitating and promoting lies and deceit, such concept would be revealed for the corrupting norm it is engendering. I certainly would not choose to follow the path suggested here in all earnestness. Lucio. On Friday, 12 October 2018 05:57:39 UTC+2, Beoran wrote: > > So no matter if I say yes or no, both ways are bad? I think is not a very > fair way to argue. > > Anyway, with the Ruby standard you can do either. The Ruby standard > defines that there are strictly conforming Ruby processors, which implement > the standard and conforming Ruby processors which may have any number of > additional implementation defined extensions, alternate syntax and language > features. > > After the standard was written, mruby was implemented to be a strictly > conforming Ruby processor, which doesn't influence or hold back the > development of the other Ruby implementations at all. > > And all other Ruby implementations can be considered confirming, which is > worth millions of $$$ to Ruby developers. The organizations and governments > I mentioned tend to have deep pockets, and the Ruby standard enables us > to gain approval from said bureaucrats. So, we can now use Ruby for these > well funded projects, since now it is an international standard. > > So actually, because the Ruby standard was carefully written to enable > this, it has been win/win for Ruby developers. You can use a strictly > conforming mruby if you like or need to, or use any other Ruby > implementations as conforming ones and please the bureaucrats. > > I consider that we should do the same for Go. When done carefully it will > also be a win/win. > > -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
So no matter if I say yes or no, both ways are bad? I think is not a very fair way to argue. Anyway, with the Ruby standard you can do either. The Ruby standard defines that there are strictly conforming Ruby processors, which implement the standard and conforming Ruby processors which may have any number of additional implementation defined extensions, alternate syntax and language features. After the standard was written, mruby was implemented to be a strictly conforming Ruby processor, which doesn't influence or hold back the development of the other Ruby implementations at all. And all other Ruby implementations can be considered confirming, which is worth millions of $$$ to Ruby developers. The organizations and governments I mentioned tend to have deep pockets, and the Ruby standard enables us to gain approval from said bureaucrats. So, we can now use Ruby for these well funded projects, since now it is an international standard. So actually, because the Ruby standard was carefully written to enable this, it has been win/win for Ruby developers. You can use a strictly conforming mruby if you like or need to, or use any other Ruby implementations as conforming ones and please the bureaucrats. I consider that we should do the same for Go. When done carefully it will also be a win/win. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
On Thu, 11 Oct 2018 06:15:16 +0200, you wrote: >But that is not what I am getting at. Five years ago I was somewhat >involved in the effort to make Ruby an ISO standard language. From the get >go it was a largely bureaucratic effort. We specified a common sub set of a >then already old version of Ruby and made enough loopholes to make sure >that any Ruby out there could be considered confirming to the standard. > >Why? You can perhaps not appreciate how powerful the bureaucrats can be in >some countries and corporations. Since Ruby became an ISO standard, I have >been able to convince those bureaucrats to let me use Ruby where I was >barred from doing so before. So, the question is are you able to use any version of Ruby, or are you restricted to the ISO version of Ruby? If you are restricted to the ISO version that it is a very bad thing because you are inherently then holding back the forward progress of the language by forcing people to use an old version. If you can use any version of Ruby then you have demonstrated that the ISO certification isn't worth the paper its printed on. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
I understand very well what the risks of standardization can be. Look at how the C language was maimed during standardization by 104 instances of undefined behavior. But that is not what I am getting at. Five years ago I was somewhat involved in the effort to make Ruby an ISO standard language. From the get go it was a largely bureaucratic effort. We specified a common sub set of a then already old version of Ruby and made enough loopholes to make sure that any Ruby out there could be considered confirming to the standard. Why? You can perhaps not appreciate how powerful the bureaucrats can be in some countries and corporations. Since Ruby became an ISO standard, I have been able to convince those bureaucrats to let me use Ruby where I was barred from doing so before. For Go language it is now the same. Bureaucrats don't know Go, and because it is not standardized, I often encounter a "no go". A Ruby style standard that would allow developers to check the "ISO standard language" box would allow us to convince those bureaucrats to let us use Go much more widely. Like Michael Jones suggest, we would only standardize Go as it is, and not use the standardization process to let it decide the language features. And only update the standard once the new features are settled. That avoids design by committee as well. For these reasons I think, when done properly, the effort will be worth while in the end. Kind Regards, B. -- 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.
Re: [go-nuts] Go language should become an ANSI and ISO standard.
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 wrote: > On Wed, Oct 10, 2018 at 7:55 AM, Beoran 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@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
Re: [go-nuts] Go language should become an ANSI and ISO standard.
On Wed, Oct 10, 2018 at 7:55 AM, Beoran 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
