4 ms·
It would be neat if there was a Go Playground running the latest beta/RC version of Go. (Or is there?) I wanted to quickly test out the new struct type convers
by maddyboo 10y ago
It would be neat if there was a Go Playground running the latest beta/RC version of Go. (Or is there?)
I wanted to quickly test out the new struct type conversion behavior and obviously my code[1] doesn't compile on the normal playground.
Perhaps interesting to note, the `beta.golang.org`[2] homepage specifically adds an inline `display:none` style to the div containing the mini Go Playground which is normally on the `golang.org`[3] homepage - removing that style in the Chrome inspector, you can see the mini Playground, but it doesn't work. Upon closer inspection, the code to init the playground is still there, but the `playground.js` script isn't – the init code, however, checks for this so it doesn't throw any errors.
I like the attention to detail, at least – you don't want the homepage for a beta version to have the plaground running the current stable release version; that would be pretty confusing. Still, I wonder why the HTML and JS initialization code for the playground is still there? If they went through the effort to add a `display:none` style to the HTML and a condition to check if the Playground script is available, why not just remove it entirely?
Just my random thoughts - obviously not a big deal at all, I just found it interesting!
[1] https://play.golang.org/p/_OSA3O2vTR https://play.golang.org/p/_OSA3O2vTR
[2] https://beta.golang.org/ https://beta.golang.org/
[3] https://golang.org/ https://golang.org/
- f2f 10y ago> It would be neat if there was a Go Playground running the latest beta/RC version of Go. (Or is there?) umm, no, not automagically. the playground is restricted. it would require some work to be put in to make it work with the latest release. that work isn't available for free.
- maddyboo 10y agoThis is why I don't comment on HN. Maybe I'm stupid and just always make stupid comments, but I think the attitude you displayed with your "umm, no" is way too common around here. Is it too hard for you to not be condescending when making a counter argument? Edit: After re-reading both my comment and yours, I'm not sure if you were using the "umm, no" innocently in response to the `(Or is there?)` at the end of my sentence, or if you were trying to say it in a condescending way. I'll give you the benefit of the doubt and assume it was the former. I'm not trying to be one of those SJW people who gets offended at any little thing. Regarding the rest of your comment: > the playground is restricted What exactly do you mean by that? > automagically And that? I'm referring to large RCs like this. I think a lot of people want to test out new features/changes without pulling the latest version to their machine right away. That work is going to have to be done anyway before the final release, right? And I can't really imagine it would be a lot of work, I would think _maybe_ a few things would break, but otherwise it should work? And if you think I mean to have the normal `play.golang.org` start using the latest RC, that's not what I mean - I would imagine it would either be on a separate subdomain, like `play.beta.golang.org`. Or, have a dropdown on the main Playground, but that might be potentially confusing?
- jerf 10y ago"What exactly do you mean by [the playground is restricted]?" The Playground is a very special build of Go. I don't even think it's open sourced, often because while you can't depend on security-by-obscurity you still don't necessarily want to just hand people the source to attack on their own. It's written to prevent people from abusing the playground, so for instance, the os package can't read real files, the time package returns constants for "time.Now()" rather than using the clock, and an arbitrary number of other changes are made to prevent abuse. How many changes it is I don't know exactly, but there's certainly a number of them. But, more importantly, the QA work for such a thing is quite substantial. Many of the changes would also preclude using the playground to investigate the new features; for instance, you can't test HTTP2 support on there since you can't open sockets or servers. Presumably updating it would require significant effort, and at the very least, it can't be afforded to make that a blocker for a release.
- arjovr 10y agohttps://github.com/golang/playground https://github.com/golang/playground
- jerf 10y agoThank you, I stand corrected.
- maddyboo 10y agoOh interesting, I didn't realize it was a very special build of Go itself. I did know it was restricted, I guess I just underestimated how difficult that is to do. I didn't think the restrictions were actually implemented in the Go source, I thought it was more a locked down container plus a few restrictions implemented externally in the Playground's server code. It would be cool to know more about this, maybe I'll take a look at the source as @arjovr linked. Thanks!
- Merovius 10y ago> Oh interesting, I didn't realize it was a very special build of Go itself. It's not. It uses NaCl (native client), but that's just a special GOOS/GOARCH pair with a supporting runtime. NaCl is what the chrome sandbox is based upon, it's cool technology :) > It would be cool to know more about this, maybe I'll take a look at the source as @arjovr linked. You can also start here: https://blog.golang.org/playground https://blog.golang.org/playground
- Merovius 10y agoUnlike f2f I do believe this should be possible without a lot of problems. NaCl isn't that special magical technology and everything that is special needs to be in an RC anyway. And even if you have any implementation bugs; the way NaCl works, this would, in the worst case, mean that the program gets killed because it contains invalid machine code or makes invalid syscalls (this confidence comes mainly from the fact that go uses the unmodified NaCl runtime for execution, which contains the appropriate check and is QA'd by the chrome team). I assume that, so far, just no one did the work, they don't want to spend the additional resources on separate playgrounds or the go team doesn't consider it a good enough idea. I'd recommend either E-Mailing golang-nuts or directly opening an issue (after checking, that there is none so far).