It's non-trivial because the web front end and sandbox back end are separate.

Perhaps the web front-end could run that exact program to find out? (and then it's cached, presumably).

While it's easy enough to run the program, I do think this would be useful to highlight clearly. It's a common source of confusion.

Here's a cheap solution: Have a "version" button which is a link to that program http://play.golang.org/p/4WfD2XfzPt and then runs it.

Actually this solution is already mentioned in the About text. It was fairly easy to discover.

I think Go playground should always run the latest version of Go, then displaying the version becomes unnecessary.

"Always run the latest version of Go" is the goal, but it's not that simple unfortunately.

@griesemer it's true, the front end could query the back end to find the version. But right now the front end is more or less stateless; I'm hesitant to add state. Will continue to ponder.

@adg Having a "Version" button that simply links to http://play.golang.org/p/4WfD2XfzPt would be entirely stateless. Ideally it should also run it, but that could still be done in a stateless way I suspect.

I have a counterproposal, make the front end responsible for declaring the
version.

The front end has a constant, say 1.5.0 encoded into it, which allows it to
display that version prominently, and also use it as a parameter to the
back end to specify the version of Go it wants to execute the sample.

If the version of the back end does not match the front end, it can return
some form of error.

Thanks

Dave

On Sat, 22 Aug 2015 03:54 Robert Griesemer notifications@github.com wrote:

@adg https://github.com/adg Having a "Version" button that simply links
to http://play.golang.org/p/4WfD2XfzPt would be entirely stateless.
Ideally it should also run it, but that could still be done in a stateless
way I suspect.

—
Reply to this email directly or view it on GitHub
#12218 (comment).

@griesemer honestly, I don't think the UI needs more buttons.

@davecheney That would mean the playground would be broken sometimes. I'd rather serve an old version of the sandbox than break the playground.

@adg

I want to submit a CL, but did not found web front playground.js in golang/playground repo.

sandbox change to response with go version, web front got it and show in html.

diff --git a/sandbox/sandbox.go b/sandbox/sandbox.go
index 7ea6bef..fb0c5e7 100644
--- a/sandbox/sandbox.go
+++ b/sandbox/sandbox.go
@@ -33,8 +33,9 @@ type Request struct {
 }

 type Response struct {
-       Errors string
-       Events []Event
+       Errors  string
+       Events  []Event
+       Version string
 }

 func main() {
@@ -58,6 +59,12 @@ func compileHandler(w http.ResponseWriter, r *http.Request) {
                http.Error(w, err.Error(), http.StatusInternalServerError)
                return
        }
+       version, err := exec.Command("go", "version").Output()
+       if err != nil {
+               http.Error(w, err.Error(), http.StatusInternalServerError)
+               return
+       }
+       resp.Version = string(version)
        if err := json.NewEncoder(w).Encode(resp); err != nil {
                http.Error(w, fmt.Sprintf("error encoding response: %v", err), http.StatusInternalServerError)
                return

@tomheng I don't want to run a 'go version' on each invocation of a sandbox program. That would add unnecessary latency to each request. I also don't want to further complicate the wire format between the playground and the sandbox.

Change https://golang.org/cl/98446 mentions this issue: playground: display the version of Go in use

Screenshot for the CL above: