18 comments

[ 2.4 ms ] story [ 54.7 ms ] thread
That seems to only work when logged in with a GitHub or Google account. That's an odd choice, https://play.golang.org/ doesn't have this limitation.
It's a completely different project, so why wouldn't it be under different constraints, e.g. funding-wise?
Since that apparently wasn't clear: Requiring a login is a basic tool to combat abuse of the service. an official golang resource likely is way better equipped both in tolerance for going "over budget" as it is in resources to invest in other filters.
If you block JS, you can at least read it.
Does this have any advantage over the official a tour of go ?
It's curated tutorials that you can execute as you click in a terminal. Try it out.
Tour of Go is an introduction to the Go language. Play with Go is not intended as a replacement for that, rather it's an interactive introduction to the tooling required to program in Go. The go command is the most obvious example of that, but modules also lend themselves well to this sort of guide.
Not sure if OP is the developer but if you are: The about page has a lot of CSS issues, footer overlapping and images scaled wrongly.
Perhaps the author is a backend developer.

The source code is open to collaboration?

It wasn't criticism of the developer, just passing the info along in case they haven't spotted it.
Why should I have to sign in? No thanks.
You get a Linux terminal, that will be why to prevent spam. The login only takes a public email address.

That's legit, think of katacoda and other e-learning platforms.

Prevent span on who, though? Generally (~99.99% of the time), providing an e-mail address is an invitation to getting spam.
Assumedly to help the site owners prevent using their service to perpetrate spam against others using the Go language services/shell?
As others have kindly pointed out, we use authentication as one means of preventing abuse of the system. Each guide is connected to a remote container instance, so there are real compute costs associated with each user's session. Leaving this open is not something that we, as a sponsor-supported open source project, can afford.