Show HN: Go playground powered by WASM that runs in the browser(go-playground-wasm.vercel.app)
go-playground-wasm.vercel.app
Show HN: Go playground powered by WASM that runs in the browser
https://go-playground-wasm.vercel.app/
44 comments
Got to admit, I think "Rewrite it in Rust" has gone too far this time.
> Goscript
> A script language like Python or Lua written in Rust, with exactly the same syntax as Go's.
Strange things are afoot at the Circle K.
Strange things are afoot at the Circle K.
Thanks. I've never seen Bill & Ted's Excellent Adventure and this comment lead me down a great little Internet rabbit hole
Stop at the first movie, both the sequels are totally heinous.
I enjoyed the newest one, but probably because it was dumb and nostalgic and I hadn't seen the original in twenty years.
What GC is used in goscript? The upstream one, a Rust GC<> one, maybe the mini one from TinyGo, or something else custom?
I poked around earlier and found this file: https://github.com/oxfeeefeee/goscript/blob/master/vm/src/gc...
Perhaps someone can shed more light on how exactly it works
Perhaps someone can shed more light on how exactly it works
From looking at it for like 20 seconds (I ain't no serious rustacean, so forgive if I'm wrong) I think they're using just a growable pool (as vectors) of each fundamental type in the Go language, then having each instance of each fundamental type be boxed in a Rc (reference counted) type so that they can count all references to each instance of each fundamental type.I believe that this can be used to get simple reference counting "for free" via the borrow checker of Rust. Probably many downsides, and apparently they don't yet implement GC of channels, but it seems like a nice straightforward way to get a script-ing/purely interpreted implementation of a language off the ground.
The Rc module with the impl - https://doc.rust-lang.org/alloc/rc/
Further docs on Rc- https://doc.rust-lang.org/book/ch15-04-rc.html
The Rc module with the impl - https://doc.rust-lang.org/alloc/rc/
Further docs on Rc- https://doc.rust-lang.org/book/ch15-04-rc.html
[Error] TypeError: i64 not allowed as return type or argument to an imported function
[f] ut (framework-a4fd281a1981cd6d009d.js:1:16748)
[f] mt (framework-a4fd281a1981cd6d009d.js:1:17899)
[f] L (framework-a4fd281a1981cd6d009d.js:1:115080)
[f] W (framework-a4fd281a1981cd6d009d.js:1:2282)
[f] Jt (framework-a4fd281a1981cd6d009d.js:1:23856)
[f] Zt (framework-a4fd281a1981cd6d009d.js:1:23074)
[N] Zt
[f] (anonymous function) (framework-a4fd281a1981cd6d009d.js:1:128011)
[f] F (framework-a4fd281a1981cd6d009d.js:1:114857)
[f] Xt (framework-a4fd281a1981cd6d009d.js:1:22889)
[N] Xt
Thanks, this is a problem with some browsers not supporting BigInt <-> Wasm i64 conversion, I just made some changes that should fix it
Perfect! The updated version works.
Nice project. Thanks for sharing.
Nice project. Thanks for sharing.
Which browsers?
Couldn't find a list but I tested it on brave, chrome, firefox, safari and it was safari that was having troubles
Off-topic: I know one of you smart folks here at HN have figured out how to do something similar to go playground in the terminal that makes it easy to write a script, and on safe it go fmt's + imports, and then runs it. Something with vim + tmux or whatever. If this is you, I'd love it if you could share it!
I use a script for this. Something like:
#!/usr/bin/env bash
{
find . -name "*.go" -print
echo package.json
} | entr bash -c '
set -euxo pipefail
clear
go fmt
clear
go build
:
'
I made this extension for VS Code that also saves the outputs to markdown, so you can save it straight to blog posts: https://marketplace.visualstudio.com/items?itemName=gobookde...
Each cell runs in a 0.3 secs on Linux, but 3 seconds + on Windows.
If you want just straight terminal check out Gomacro, that's a interpreter that runs really fast, didn't find any differences to compiled Go.
Each cell runs in a 0.3 secs on Linux, but 3 seconds + on Windows.
If you want just straight terminal check out Gomacro, that's a interpreter that runs really fast, didn't find any differences to compiled Go.
There's an REPL called yaegi, but it's pretty primitive (no autocompletion etc.. when I tried).
There seems to be another interpreter that seems to be able to provide some autocomplete using some other third party tool, but it seemed to run from beginning every time (same effect as `go run`) and I havent tried it.
There seems to be another interpreter that seems to be able to provide some autocomplete using some other third party tool, but it seemed to run from beginning every time (same effect as `go run`) and I havent tried it.
The issue with these REPLs is for whatever reason it doesn't come close to the experience of say the python REPL. I have been hoping for the Go devs to build a REPL into the tooling but so far nothing has happened yet.
Yeah they are very primitive :(
I would love if wasm got some more TLC from the go team. Output sizes are massive compared to rust or C. I think it’s just a matter of adding some tree shaking … but probably easier said than done.
I’ve been falling more and more in love with wasm … so many possibilities :)
I’ve been falling more and more in love with wasm … so many possibilities :)
I would like that too but probably wont happen.
There are 3 big reasons for large Go binaries.
1. Unicode data is ~1 MB. It's needed to implement all the unicode-aware string functions like strings.EqualFold()
2. reflection. For reflection to work, every struct used in a Go program needs to have a description information that tells names and types of all fields. This adds up
3. Precise garbage collector also requires struct descriptions like reflection but even more information like: layout of stack frame for every function.
Those are problems that could, in theory, be worked-around.
A build could exclude Unicode info and functions that require it.
A different garbage collector could be used that doesn't require knowing layout of structs and stack frames.
Reflection could be changed to require explicit opt-in (99% of structs are not reflected upon).
Realistically none of that will happen in the official Go implementation. For better or worse most of the work is sponsored by Google and Google runs Go on servers. With 512 MB of memory, it makes little difference if your binary is 10 MB vs 9 MB, especially if you compete with even more bloat (in runtime memory use, not necessarily binary size) of Java / Python / Ruby / Node.
There are a couple of not-very-mature Go-like implementation that are trying to address this (tinygo, emgo) but they have long way to go.
There are 3 big reasons for large Go binaries.
1. Unicode data is ~1 MB. It's needed to implement all the unicode-aware string functions like strings.EqualFold()
2. reflection. For reflection to work, every struct used in a Go program needs to have a description information that tells names and types of all fields. This adds up
3. Precise garbage collector also requires struct descriptions like reflection but even more information like: layout of stack frame for every function.
Those are problems that could, in theory, be worked-around.
A build could exclude Unicode info and functions that require it.
A different garbage collector could be used that doesn't require knowing layout of structs and stack frames.
Reflection could be changed to require explicit opt-in (99% of structs are not reflected upon).
Realistically none of that will happen in the official Go implementation. For better or worse most of the work is sponsored by Google and Google runs Go on servers. With 512 MB of memory, it makes little difference if your binary is 10 MB vs 9 MB, especially if you compete with even more bloat (in runtime memory use, not necessarily binary size) of Java / Python / Ruby / Node.
There are a couple of not-very-mature Go-like implementation that are trying to address this (tinygo, emgo) but they have long way to go.
much reflection can also be done through the host environment especially since it has full access to the data and custom name sections
I agree with everything you said. Reflection, I think, is the one that is quite difficult to address.
The others - GC and unicode data - can be addressed through changes to WebAssembly in theory.
For Zig, I developed a custom compression algorithm[0] for the Unicode data files needed to implement the same string functions - reducing the data size down to just 58 KiB. The same could certainly be applied to Go.
[0] https://devlog.hexops.com/2021/unicode-data-file-compression
The others - GC and unicode data - can be addressed through changes to WebAssembly in theory.
For Zig, I developed a custom compression algorithm[0] for the Unicode data files needed to implement the same string functions - reducing the data size down to just 58 KiB. The same could certainly be applied to Go.
[0] https://devlog.hexops.com/2021/unicode-data-file-compression
great points. I’ve used tinygo, it is pretty awesome unfortunately the features I was using weren’t supported; I was utilizing some public key cryptography.
I will have to check out emgo; first time I’m hearing about it.
I will have to check out emgo; first time I’m hearing about it.
I wonder how tinygo works for wasm. I’m not sure how much of the bloat is runtime (which I assume is smallish) vs how much of the standard library is just included by default.
Tinygo produces very small binaries (kb rather than mb), through using the LLVM tool chain (which does tree shaking), and only (presently) supporting a subset of the standard library.
Plus their own (simplified) subset of the standard library, which is getting more comprehensive over time, but is nowhere near complete yet.
Plus their own (simplified) subset of the standard library, which is getting more comprehensive over time, but is nowhere near complete yet.
You can have a go at it over here, https://ebiten.org/examples/
I was sure wasm was going to replace javascript by now, still waiting though. Is it ever going to happen?
You might already know this, but WASM isn't even at a stage where it can replace JS. Bindings to the browser APIs are currently done through a JS bridge, which can be pretty slow.
I've lost track of the process (there were several proposals) so I'm not sure where we're at now.
I guess not much changed, so the current state of WASM is mostly for porting and running non-JS code (such as Go's here) in the browser.
It's also faster than JS (if passed through an optimizing compiler) so it might be useful for non-IO-bound code.
Outside the browser it's being used as a sort of universal bytecode (a la JVM). https://wasmer.io/
I've lost track of the process (there were several proposals) so I'm not sure where we're at now.
I guess not much changed, so the current state of WASM is mostly for porting and running non-JS code (such as Go's here) in the browser.
It's also faster than JS (if passed through an optimizing compiler) so it might be useful for non-IO-bound code.
Outside the browser it's being used as a sort of universal bytecode (a la JVM). https://wasmer.io/
Nice, maybe add some line numbers to the source view. Makes dealing with compile errors a bit easier.
Having a bigger / resizeable output box would help too - running the Fibonacci example, all I can see is "0" unless I manage to find the tiny box with its invisible boundary to scroll in.
awesome! I made one just like it about a year ago: https://app.qvault.io/playground/go
it actually powers some of the courses in go that I've written as well
it actually powers some of the courses in go that I've written as well
nice, i’d love to see a mobile web browser that supports wasm
offtopic: I love your username, zackoverflow
neat project too!
neat project too!
thanks! when I came up with it I couldn't believe I hadn't thought of it earlier lmao
Here's the source code (https://github.com/zackradisic/go-playground-wasm) if you would like to look at it and do something similar with your own projects.
I'm really excited for the future of goscript, Go is a great candidate for a scripting language thanks to its minimalistic design choices.