[ANN] GopherJS, a transpiler from Go to JavaScript (Go in your browser!)

[Richard Musiol]

Hi all,

I would like to announce GopherJS, a transpiler from Go to JavaScript. It translates Go code to pure JavaScript code and gives you the opportunity to write front-end code in Go which will still run in all browsers.

https://github.com/neelance/gopherjs

Enjoy!

Richard

[Vincent Callanan]

Manna from Heaven!

[robert...@gmail.com]

Great work! - Do you have a plan for how you'll approach the implementation of goroutines/select etc.?

On Monday, 13 January 2014 11:57:17 UTC, Richard Musiol wrote:

[Richard Musiol]

Thank you! Yes, goroutines are on the roadmap, see https://groups.google.com/d/msg/gopherjs/ABPk7D9nZYY/IWpU7vUnx5UJ .

[Job van der Zwan]

Now, I don't have the slightest idea of how it works, because I don't work with Clojure, but perhaps its core.async library is worth taking a look at, since it seems to have something like channels and also works for clojurescript?

[Henrik Johansson]

Core.async was created with Go channels as an inspiration. Rich Hickey apparently liked the Go channels so much that he created the same for Clojure.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Job van der Zwan]

I'm aware, my point was that since they managed to make it work for their compiles-to-javascript version, they has a solution for making it work. I have no idea what solution, but it might be worth checking out?

[Caleb Spare]

To mimic the core.async approach would require converting blocking code to asynchronous, callback-based JS. It would be very cool, but presumably involve some clever engineering -- you're writing a scheduler which decides what to run every time the code reaches a 'block' point (mutex.Lock, select, etc).

-Caleb

[Scott Pakin]

On Monday, January 13, 2014 4:57:17 AM UTC-7, Richard Musiol wrote:

I would like to announce GopherJS, a transpiler from Go to JavaScript. It translates Go code to pure JavaScript code and gives you the opportunity to write front-end code in Go which will still run in all browsers.

 

Looks promising!  I just tried it out on a trivial test case, and it does work as advertised.  Here are a few ideas that popped into my head from this initial experience:

• Generate a separate .js file for each imported package so one can do a <script src="…"> to load the same helpers from multiple GopherJS-produced top-level routines (and thereby more easily cache them on the client).
• Provide a Go interface to the DOM that might do nothing when called from native Go but translate naively into JavaScript when called from GopherJS.  For example, as a programmer it'd be cool to be able to work with, say, gopherjs.Document.GetElementById("golang").innerHTML directly in Go and not have to worry about explicitly interfacing the two languages.
• Optimize the performance of the generated code with asm.js annotations to help out the JIT compiler.  Because you already know the types of all the data from Go, I'd think this wouldn't be too difficult to implement, but what do I know?

Anyway, thanks for writing GopherJS.  I can see it coming in handy.

— Scott

[Jesper Louis Andersen]

On Mon, Jan 13, 2014 at 11:46 PM, Caleb Spare <ces...@gmail.com> wrote:

To mimic the core.async approach would require converting blocking code to asynchronous, callback-based JS. It would be very cool, but presumably involve some clever engineering -- you're writing a scheduler which decides what to run every time the code reaches a 'block' point (mutex.Lock, select, etc).

This is a well-known CPS tranformation (continuation passing style). I would guess this would be the approach Clojure took.

--
J.

[distributed]

Kudos to Richard for this fascinating project.

To get a feel for performance I ran my only CPU-bound code that doesn't need goroutines through GopherJS and executed it with node. It's an integery 6502 instruction set simulator. After a couple of seconds of warmup the GopherJS compile code running on node/V8 is taking about double the run time of the same code compiled with 6g for darwin/amd64. I think that's very impressive.