Thanks for the proposal.

A code snippet was written and shared in Go 1.x. Over time, its shared link may have corrupt running result if Go 1.y (where y > x) introduces forward or backward compatibility issues.

Go does not break backward compatibility (see https://golang.org/doc/go1compat), so in practice this should not be an issue. A correct piece of code that compiled on go1.5 will still work on a playground that is on go1.13.

Forward compatibility is also not really an issue. Yes, you may have some runnable example on tip.golang not work for a few weeks, but tip.golang is not the website you should visit anyway. It's just a staging place for the upcoming website. Once the a new version is released and the website at golang.org is updated, the playground will be updated too and the runnable examples will work.

The only practical use of a multi-version playground I can imagine is to compare the generated machine code on different Go versions (e.g. to demonstrate better optimizations or show a regression), since that is not stable between releases, and can change; but the playground does not support disassembling anyway (and I think it would be out of scope), moreover you can use godbolt for that (it's literally its point), which already supports all the old Go versions.

@ALTree Thanks for clarifying backward compatibility promise. I awarded it and that is why I added "Other consideration" with Go 2 paragraph. However, as long as future Go 2 breaks the backward compatibility, the code snippet shared in Go 1 will break.

Moreover, another use case for supporting all versions of Go can help Go user exploring bugs of Go. For instance, a code snippet that illustrates a compiler or runtime bug in Go 1.x, but the bug was fixed in Go 1.y (where y > x). Therefore, the code snippet can lose its interpretability of the bug.

For instance, a code snippet that illustrates a compiler or runtime bug in Go 1.x, but the bug was fixed in Go 1.y (where y > x). Therefore, the code snippet can lose its interpretability of the bug.

This is true but to be honest it doesn't seem a use-case that compelling.

The observation about Go2 is more interesting, and I agree that if a future Go2 breaks backward compatibility then we'll want to have a playground that supports at least 1) the latest/current version and 2) the latest Go1 version.

But this is quite different from what you were asking here in the original post (support of every Go1 version). If this is just about a dual Go1/Go2 playground, it seems premature to worry now.

cc @andybons

But this is quite different from what you were asking here in the original post (support of every Go1 version). If this is just about a dual Go1/Go2 playground, it seems premature to worry now.

@ALTree I think there may have some misunderstanding between Go 1.x and Go 2.

The reason I keep uses Go 1.x rather than Go 2 in the Proposal section because all announced articles [1, 2, 3], delivers the message that the Go 2 may never be annotated as the official name but arrives in several different releases of Go 1.x, e.g. Go 1.11 for modules, Go 1.13 for errors, Go 1.15 for generics, and so on. This is actually the reason I mentioned in "Other consideration", starting from Go 1.11, "Go is under the transition to Go 2". Basically, I use "Go 1.x" to mix the terminology of Go 1 and Go 2 in the proposal.

Towards to have two separate Go1/Go2 playgrounds: if the APIs to Playground is designed well and clean for two incompatible versions of Go, then it is not that difficult to support all versions of Go, isn't it? Unless we arguing support all different versions of Go are wasting server resources. However, this isn't true because VM nowadays scales in seconds upon requests.

[1] https://blog.golang.org/toward-go2
[2] https://blog.golang.org/go2-next-steps
[3] https://blog.golang.org/experiment

Now that we can specify the language version in go.mod file and the compiler's -lang flag, it kind of already does: https://play.golang.org/p/B4ARI9cL3A4

What you are describing is a lot of work for the Go team, because we run play.golang.org, for diminishing benefit. Actually keeping old versions of software running is non-trivial effort.
And as multiple people noted, backwards compatibility means that there's not much difference
between the latest and the older ones.

If someone wanted to run a different site that had all the versions, that'd be great. But the cost-benefit here for the Go team does not seem like it works out.

This seems like a likely decline.

Leaving open for a week for final comments.

@bradfitz points out that the current playground backends do already support selecting between different compiler trees. Especially given #34536, maybe we should support the last two releases? What's missing is UI to select a specific version.

To be clear, this would only be supported versions, not all versions. With that restriction, the burden may be less.

We could possibly also add tip, but that would require more work in the backends to refresh tip regularly.

It is still unclear who would do the work, but at least limiting the proposal to supported versions would address the ongoing burden. We could accept this and move it to Backlog until someone is interested.

Change https://golang.org/cl/195983 mentions this issue: sandbox: add gvisor runsc-based sandbox

Sorry, this was meant to go back to Active earlier, not Accepted.

Based on discussions with @bradfitz, this sounds fairly straightforward to do.
In addition to the UI for a drop-down, we'd want a version=go1.13 URL parameter
in the URL bar when the non-default toolchain has been selected,
and that would be copied in by the Share button so that it's visible and easy to change.
But if the default toolchain is in use the Share button would not add any version=,
to keep URLs short.

This now seems like a likely accept.

Leaving open for a week for final comments.

No change in consensus, so accepted.

Going in the opposite direction from supporting older versions, how difficult would it be for the Go playground to provide the ability to run Go code using CLs uploaded to Gerrit? E.g., could the trybots automatically build a compiler-tree artifact and store it in GCS somewhere that the Go playground can use (maybe for N days or until the CL is merged or something, to limit storage costs)?

I've seen projects that will generate a preview website for each active PR so reviewers can easily see the results. Occasionally, when reviewing compiler CLs, I want to double check that it still handles some cases correctly; currently I'll typically download the CL and build/verify myself, but this is inconvenient sometimes. Also, I like uploading proof-of-concept CLs for language change proposals; it might make it more accessible to non-project-members (folks who aren't used to downloading Gerrit CLs and building locally) if they could experiment with these via the Go playground.

If this is at all reasonable, I can file a separate proposal to discuss this further. But if scaling the playground from supporting <10 versions to 100s of versions is going to be technically prohibitive, then I'll leave it be.

Matthew, the builders already do store the result of make.bash to GCS. Forever. For years now. Unless something changed recently. So probably wouldn't be hard to grab an alternate tarball from the network.

I think it would be enough to support the two latest a
versions, as well as the tip for experimenting with new language features, in essence 1.18 generics.

I realize that I'm a bit late to the discussion, but I had a thought. The Playground has the ability to use remote dependencies, though it seems that it's started printing out go vet warnings because of the go.mod not being tidied. Much like the version of Go itself, it would be nice to be able to pick versions for dependencies. Would it be feasible to deal with both birds by making it possible to just directly edit the go.mod file that the playground is using for the compilation?

@DeedleFake that's already possible, an example is selecting the multiple files example

So it is. I had no clue that that feature had been added. Neat. Thanks.

I believe this proposal is implemented now and live at https://go.dev/play since golang/website@13fd016. Therefore I am closing this issue. If not, feel free to reopen this again.