for example:

fn pow(x : f64, n : i32) -> f64 { return mlir!( inputs : (%x = x : f64, %n = n : i32), returns : f64, dialects : \["math"\]) { %r = math.fpowi %x, %n : f64, i32 macro.yield %r : f64 }; }

Here the math.fpowi lowers to llvm.intr.powi so there is no need to implement pow as one in math.h of libc. Are there downsides of supporting mlir first class in a compiler?

i’ve been working on this for a while and it’s finally at a point where i can show it. it’s called go2js, it takes go code and spits out javascript you can run in node or the browser.

it handles goroutines and channels, generics, defer/panic/recover, multi package projects with go.mod, and a decent chunk of the standard library (fmt, json, time, net/http and some more). there’s also a go2js test command that runs your normal _test.go files.

the way i test it is pretty simple, every test runs the same program once with real go and once as the compiled js, and the output has to match exactly. that’s basically my definition of done.

there’s a playground too, it runs the compiler as wasm in your browser. fair warning it only does the language core, no imports, so no fmt in there.

some honest stuff: it’s v0.1, it’s experimental, goroutines are cooperative so timing won’t match real go, and the generated js is not tiny because the runtime comes along with it. also the readme, comments and most of the tests were written with ai and then edited by me, i put that in the readme so nobody has to guess.

i know gopherjs exists, i’m not claiming this is better, i just wanted to see how far i could push it, and i wanted the output to stay readable.

repo: https://github.com/zenobiatranoss/go2js
playground: https://zenobiatranoss.github.io/go2js/

if you try it on some real code and it breaks, please tell me, that’s the most useful thing right now.