New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: delete mention of compiled binaries from spec #22282

Closed
dlsniper opened this Issue Oct 15, 2017 · 20 comments

Comments

Projects
None yet
10 participants
@dlsniper
Contributor

dlsniper commented Oct 15, 2017

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

This comment has been minimized.

Contributor

dlsniper commented Oct 15, 2017

cc @gopherjs (iirc this should work)

@dlsniper dlsniper changed the title from Consider GopherJS as an implementation and mention it in The Go Programming Language Specification to proposal: doc: Consider GopherJS as an implementation and mention it in The Go Programming Language Specification Oct 15, 2017

@gopherbot gopherbot added this to the Proposal milestone Oct 15, 2017

@gopherbot gopherbot added the Proposal label Oct 15, 2017

@cznic

This comment has been minimized.

Contributor

cznic commented Oct 15, 2017

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

@dlsniper

This comment has been minimized.

Contributor

dlsniper commented Oct 15, 2017

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

This comment has been minimized.

Member

ALTree commented Oct 15, 2017

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

This comment has been minimized.

Contributor

dlsniper commented Oct 15, 2017

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

This comment has been minimized.

Member

ALTree commented Oct 15, 2017

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

it can compile Go code

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

@dlsniper

This comment has been minimized.

Contributor

dlsniper commented Oct 15, 2017

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

This comment has been minimized.

Member

dmitshur commented Oct 15, 2017

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

This comment has been minimized.

Member

jimmyfrasche commented Oct 15, 2017

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

@dmitshur

This comment has been minimized.

Member

dmitshur commented Oct 15, 2017

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

This comment has been minimized.

Contributor

dlsniper commented Oct 15, 2017

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

This comment has been minimized.

Contributor

cznic commented Oct 15, 2017

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

This comment has been minimized.

Member

jimmyfrasche commented Oct 15, 2017

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

This comment has been minimized.

Contributor

cznic commented Oct 15, 2017

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

This comment has been minimized.

Member

ALTree commented Oct 15, 2017

@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

This comment has been minimized.

Contributor

as commented Oct 16, 2017

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

This comment has been minimized.

j7b commented Oct 17, 2017

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

This comment has been minimized.

Contributor

rsc commented Oct 23, 2017

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."

@rsc rsc changed the title from proposal: doc: Consider GopherJS as an implementation and mention it in The Go Programming Language Specification to doc: delete mention of compiled binaries from spec Oct 23, 2017

@rsc rsc added Proposal-Accepted and removed Documentation labels Oct 23, 2017

@rsc rsc modified the milestones: Proposal, Go1.10 Oct 23, 2017

@dlsniper

This comment has been minimized.

Contributor

dlsniper commented Oct 23, 2017

Sounds great, thank you!

@gopherbot

This comment has been minimized.

gopherbot commented Oct 23, 2017

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

@gopherbot gopherbot closed this in 0c5b00d Oct 23, 2017

@golang golang locked and limited conversation to collaborators Oct 23, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.