Is there a webassembly compiler for Go in the works?

<p>Does anybody know if Google or somebody else is working on a Go compiler for wasm? If not, any idea when something like that may be available (6 months, 1 year, 2 years...?)?</p> <hr/>**评论：**<br/><br/>dgryski: <pre><p>Here&#39;s the tracking bug: <a href="https://github.com/golang/go/issues/18892">https://github.com/golang/go/issues/18892</a></p></pre>mentally_lazy: <pre><p>Thanks for that link. Reading that gives me the impression that it will take a long long time until such a compiler is available for Go. It may be better to learn Rust in order to use wasm in the meantime.</p></pre>neoasterisk: <pre><p>I see sbinet in the comments which is a very good sign. He makes things happen.</p></pre>AluekomentajaArje: <pre><p>I would imagine the consensus being reached (see <a href="https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html">here</a>) put the gears in motion, as it looks very likely that it will happen across browsers and Go can&#39;t really afford to not have a wasm backend if it turns out to be the winning technology in the future (as seems likely to me).</p></pre>mentally_lazy: <pre><p>Ok, I accept that statement and wait silently now.</p></pre>snippet2: <pre><p>I think a good first approach would be a HTML interpreter in go. Although it isn&#39;t much of a step but would be fun. <a href="https://golang.org/pkg/html/template/#HTML" rel="nofollow">https://golang.org/pkg/html/template/#HTML</a></p></pre>ar1819: <pre><p>Last time I checked - there were no general consensus of how to implement GC properly in wasm. That remains for the future works. </p> <p>As a side note - as much as I like wasm concept, it&#39;s not yet ready for general use. It may be interesting technology to play with (or even design some computation heavy apps) but there is no facilities yet to manipulate DOM for example. Details: <a href="http://stackoverflow.com/questions/42628328/wasm-access-dom" rel="nofollow">http://stackoverflow.com/questions/42628328/wasm-access-dom</a></p></pre>snippet2: <pre><p>I never understood why use wasm if go already takes advantage of multi threads and processors?</p></pre>LimEJET: <pre><p>webasm is for the web. As in, client side.</p></pre>snippet2: <pre><p>Why not a go browser?</p></pre>AluekomentajaArje: <pre><p>Because 99% of the people in the world will not switch browsers to support some random webapp. The use case here is to write software in Go that runs in all (future) browsers.</p></pre>snippet2: <pre><p>I don&#39;t understand, they&#39;re building an automated assembly language with go. <a href="https://youtu.be/KINIAgRpkDA" rel="nofollow">https://youtu.be/KINIAgRpkDA</a> They built whole OS&#39;s in go. Even Firefox works with go and has been since 2014. Why should the future be slower and limited?</p></pre>AluekomentajaArje: <pre><blockquote> <p>Why should the future be slower and limited?</p> </blockquote> <p>I&#39;m not sure slower is an issue with the use cases for wasm - although, it probably will improve performance in browser apps in general - as the programs that this would target would be web applications (think reddit <em>frontend</em>, not the backend). As for limited - I&#39;d argue being able to run your program on pretty much all devices that people commonly use these days is <em>not</em> a limitation. The browser is quickly turning into a platform and I would personally put my money behind it being the dominant platform for frontends pretty soon. </p> <p>Also, allowing one to write the frontend with Go allows the developer (you) to use that same language for both the front- and backend and share code between them (at least theoretically) reducing the amount of code you&#39;ll be needing to write and reducing the likelyhood of bugs. It&#39;s <em>more</em> choices for you as the developer, not less.</p> <p>edit; think of it more like the fact that Go can compile your program to either ARM or x86 architecture (eg. Macs and PCs .. plus many more architectures too) and this will be just another architecture you can target, it just happens to live in a browser that&#39;s accessible to most of the people in the world.</p></pre>TheMerovius: <pre><p>Because you usually don&#39;t try to cater for yourself with Webapps, but to other people.</p></pre>snippet2: <pre><p>You have a point. Google did spend all that time on the v8 to make it much quicker. But they also spent all that time on Python to make it quickly too. I just hope it&#39;s some how in the works. Because you can&#39;t compare JS&#39;s maintainability to go. But your point still stands again. :(</p></pre>AluekomentajaArje: <pre><blockquote> <p>Because you can&#39;t compare JS&#39;s maintainability to go.</p> </blockquote> <p>And this is <em>exactly</em> why a wasm backend for Go would be a good thing; It allows us to write maintainable Go instead of unmaintanable JS to write those apps!</p></pre>p4r14h: <pre><p>Oh man, you&#39;re right! Why don&#39;t you let Facebook, Google, Apple etc know so they don&#39;t waste their time? Obviously the solution is to simply rewrite everything in Go since it&#39;s faster and unlimited. </p></pre>