Go: doc: delete mention of compiled binaries from spec

[dlsniper]

Hi,

I was just rereading the Go specifications and I realized that the introduction text could be changed.
The current specifications state:

The existing implementations use a traditional compile/link model to generate executable binaries.

However, GopherJS, https://github.com/gopherjs/gopherjs , has been around for a while now and it supports all the language features. GopherJS transpiles Go code to JavaScript in order to get it to run. I believe that the effort behind it should be highlighted in the specifications as such.

According to their README: https://github.com/gopherjs/gopherjs#what-is-supported the language support is there. The fact that it does not implement the whole _current_ standard library can be seen here: https://github.com/gopherjs/gopherjs/blob/master/doc/packages.md and it's not related to the language specifications.

What do you think?

[dlsniper]

cc @gopherjs (iirc this should work)

[cznic]

IINM, GopherJS does not implement the Go language specification and thus cannot be considered to be an implementation of the same.

[dlsniper]

Please argument why you believe this:

IINM, GopherJS does not implement the Go language specification and thus cannot be considered to be an implementation of the same.

According to their README: https://github.com/gopherjs/gopherjs#what-is-supported the language support is there. The fact that it does not implement the whole _current_ standard library can be seen here: https://github.com/gopherjs/gopherjs/blob/master/doc/packages.md and it's not related to the language specifications.

I've updated the issue description to reflect it.

[ALTree]

The fact that it does not implement the whole current standard library [..]

I don't understand what does this mean. If they can compile all valid go code, why is a library like go/types (which is written in pure go) marked as "not supported"?

[dlsniper]

I don't understand what does this mean. If they can compile all valid go code, why a library like go/types (which is written in pure go) is marked as "not supported"?

I don't have any insights into that but again, it should not matter if it can compile the Go code and have it running according to the specifications. The standard library and the languages specifications are two separate things in my opinion and should not be tied together.

[ALTree]

I'm confused.. I'll rephrase my question.

it can compile Go code

can it compile go/types? It's go code.

[dlsniper]

I'll rephrase my question.
can it compile go/types? It's go code.

Sorry for misunderstanding this. GopherJS compiles that package just fine, however it doesn't offer it to users because of the way GopherJS works.

For example net/http is also flagged as Partial because client only, emulated via Fetch/XMLHttpRequest APIs; node.js requires polyfill but it doesn't mean that GopherJS won't compile the code because the code is not parsable. It just doesn't have a way to run a web server in the browser (yet).

Thus my request not to conflate the language specifications with the Go standard library provided by the Go implementation created by Google and this implementation. They are different things.

[dmitshur]

can it compile go/types? It's go code.

Yes, it can.

$ gopherjs build go/types
$ echo $?
0

If they can compile all valid go code, why is a library like go/types (which is written in pure go) marked as "not supported"?

A package is considered to be fully supported if all of its test pass. Not all of go/types tests currently pass, that's why GopherJS doesn't mark it as officially supported.

I don't understand what does this mean. If they can compile all valid go code

The implementation has documented limitations. Cgo is not supported. Package unsafe is not supported. System calls are not supported in the browser (they are supported when running via node though). GOMAXPROCS is set to 1 and cannot be changed.

[jimmyfrasche]

Package unsafe is part of the language specification but listed as unsupported.

[dmitshur]

I believe that the effort behind it should be highlighted in the specifications as such.

Why? The goal of The Go Programming Language Specification is to specify the Go programming language, not to list all existing implementations. It doesn't list gc or gccgo anywhere, why should it list GopherJS?

(Such a list can exist elsewhere, perhaps on a wiki page.)

[dlsniper]

Why?

Because this is incorrect:

The existing implementations use a traditional compile/link model to generate executable binaries.

If we take GopherJS into consideration.

[cznic]

I do consider the GopherJS project to be amazing and useful - even when I've never used it so far. I definitely would give it a try once I have a opportunity to do so.

The above is not enough to make GopherJS a Go specification-conforming implementation. But certain restricted execution enviroments may not be ever able to support a conforming implementation. C specs distinguish that as 'hosted' and 'free-standing', IIRC. It seems GopherJS can never implement the "full" Go specs. _Maybe_ it'd make sense to have/define some restricted subset of the Go specs in a similar sense, but I think it's probably better to not do so.

[jimmyfrasche]

I agree that it seems unnecessary to include that particular sentence in the specification which is supposed to describe necessary properties for an implementation and not to describe existing implementations.

[cznic]

There's nothing intrinsically wrong in mentioning traditional/existing methods of implementations in the specification. After all, conforming implementations are still free to use any "non-traditional" methods.

[ALTree]

@dlsniper @shurcooL Thanks for clarifying. Now it's clear why pure-go packages can too be marked as unsupported. I assumed that meant "it's currently not compilable by gopherJs".

[as]

When a user reads a specification, does that user want to see that type of thing?

1.) Here's how it works
2.) Here's a third party library that uses this made it work in a different way

I look for the first one. Even if it passes all the tests, why does that matter? The criteria shouldn't even exist at all. The spec should be reworded to say The official implementation uses a traditional compile/link model to generate executable binaries. and drop the plurality altogether. This gives users the hint that there is a potential salad bar of implementations, but it retains the simplicity of the spec.

[j7b]

I'm a big fan of gopherjs but there's areas of noncompliance with the language specification, for example goroutines continue to run after main returns, so it wouldn't be a candidate for inclusion if there were a list of implementations.

It's probably better to think of gopherjs as a standalone implementation of a buildmode.

[rsc]

Per discussion with @ianlancetaylor, @spf13, @pjweinb, @griesemer, let's just delete this sentence from the spec:

"The existing implementations use a traditional compile/link model to generate executable binaries."

[dlsniper]

Sounds great, thank you!

[gopherbot]

Change https://golang.org/cl/72792 mentions this issue: spec: remove sentence discussing existing implementations