Skip to content
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

x/playground: allow selecting supported versions of Go #33629

Open
changkun opened this issue Aug 13, 2019 · 12 comments
Open

x/playground: allow selecting supported versions of Go #33629

changkun opened this issue Aug 13, 2019 · 12 comments

Comments

@changkun
Copy link
Contributor

@changkun changkun commented Aug 13, 2019

Motivation

Go Playground was introduced in 2010 [1] and provides a great service that not only allows Go users exploring code snippet of Go but also supports all online document examples.

However, the playground only supports the latest version of Go, which may cause an issue: 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.
The other example appears in tip.golang.org. The tip.golang.org illustrates the latest beta version of Go, but only uses the latest stable release of Go. If the latest beta contains API changes, the document example will be corrupted. E.g. the example [2] regarding API errors.As corrupts in Go 1.13 betas.

Proposal

Allow Go Playground support all releases of Go compiler, including beta releases, and gccgo. This enables Go users being able to share code snippet with a specific version of Go, as well as powering beta document release in tip.golang.org.

Other consideration

  • Go is under the transition to Go 2, and considerably, future Go versions will introduce more API changes, especially if Generics feature is released (e.g. package sort, container and etc.)
    Such a feature allows Go users to share and compare results in different versions.

  • It is worth mentioning that Compiler Explorer [3] is a famous tool that shows the assembly output of C++ compilers which allow C++ users to explore language changes and performance tunning process. There is already an online version exists [4] which dedicated for Go with few limited supported versions. But this may be an advanced feature that does not need to all Go users.

  • Services that rely on the Go Playground need to adapt to the changes of Go Playground.

[1] https://blog.golang.org/playground
[2] https://tip.golang.org/pkg/errors/#As
[3] https://godbolt.org/
[4] https://go.godbolt.org/

@gopherbot gopherbot added this to the Proposal milestone Aug 13, 2019
@gopherbot gopherbot added the Proposal label Aug 13, 2019
@ALTree

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Aug 14, 2019

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.

@changkun

This comment has been minimized.

Copy link
Contributor Author

@changkun changkun commented Aug 14, 2019

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

@ALTree

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Aug 14, 2019

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

@changkun

This comment has been minimized.

Copy link
Contributor Author

@changkun changkun commented Aug 14, 2019

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

@cherrymui

This comment has been minimized.

Copy link
Contributor

@cherrymui cherrymui commented Aug 14, 2019

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

@rsc rsc added this to Incoming in Proposals Dec 4, 2019
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Dec 11, 2019

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.

@rsc rsc moved this from Incoming to Likely Decline in Proposals Dec 11, 2019
@changkun

This comment has been minimized.

Copy link
Contributor Author

@changkun changkun commented Dec 11, 2019

Just revisited the proposal: the proposal didn't provide enough impact to the community and didn't consider the future costs of maintaining the feature, which solves a trivial problem but creates tons of potential problems.

Agree on "clear rejection".

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Jan 8, 2020

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

@rsc rsc moved this from Likely Decline to Accepted in Proposals Jan 8, 2020
@rsc rsc changed the title proposal: x/playground: support all versions of Go proposal: x/playground: allow selecting supported versions of Go Jan 8, 2020
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 8, 2020

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

@rsc rsc moved this from Accepted to Active in Proposals Jan 8, 2020
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Jan 8, 2020

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

gopherbot pushed a commit to golang/playground that referenced this issue Jan 8, 2020
This creates a VM (running Container-Optimized OS) with configuration
such that it boots up and downloads/configures the runsc Docker
runtime, reloading the existing Docker daemon on the VM, and then
creates a new privileged Docker container with the host's
/var/run/docker.sock available to the container. From within that
container it's then possible for the new sandbox HTTP server to create
its own Docker containers running under gvisor (using docker run
--runtime=runsc).

This then adds a regional us-central1 load balancer and instance group
manager & instane template to run these VMs automatically across
us-central1. Then the play.golang.org frontend can hit that URL
(http://sandbox.play-sandbox-fwd.il4.us-central1.lb.golang-org.internal)

Fixes golang/go#25224
Updates golang/go#30439 (remove nacl)
Updates golang/go#33629 (this CL makes the playground support 2 versions)

Change-Id: I56c8a86875abcde9d29fa7592b23c0ecd3861458
Reviewed-on: https://go-review.googlesource.com/c/playground/+/195983
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Jan 15, 2020

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.

@rsc rsc moved this from Active to Likely Accept in Proposals Jan 15, 2020
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Jan 22, 2020

No change in consensus, so accepted.

@rsc rsc moved this from Likely Accept to Accepted in Proposals Jan 22, 2020
@rsc rsc changed the title proposal: x/playground: allow selecting supported versions of Go x/playground: allow selecting supported versions of Go Jan 22, 2020
@rsc rsc modified the milestones: Proposal, Unreleased Jan 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
5 participants
You can’t perform that action at this time.