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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
