Someone write a golang-ast-to-asm.js compiler... then we can "run our go code in the browser"!

[Philipp Schumann]

Just stumbled upon this:

http://asmjs.org/spec/latest/

Could be neat for compiling Go code (except syscalls etc. of course) to JS without dealing with all kinds of JS messyness...

Any takers?  ;)

[John Nagle]

Why? The result would be less efficient than writing in Javascript.

Compiling to Java byte code might be more promising.

John Nagle

[Patrick Mylund Nielsen]

Not everyone is in love with JavaScript.

Java bytecode doesn't run in browsers. The whole point of asm.js is to try to make a language we're forced to live with (JavaScript) very efficient, a la C--, so that we can target browsers, mobile devices, etc. trivially with other languages.

See Emscripten and friends.

--
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.

[Archos]

It's easy since there is already a compiler that translates over 85-90% of Go's specification. Fork it to target asmjs.

https://github.com/kless/go2js

Note that Go2js project is in stand by since I've no time for it.

[Niklas Schnelle]

As far as I know asm.js is specifically designed to make code generated by Emscripten easier to optimize while being still Javascript, excutable by any JS engine.
So an asm.js aware engine can execute it as fast as Java or C# while it still runs on every browser. Emscripten is based on LLVM and compiles
LLVM bitcode to JS/asm.js there is a Go compiler targeting LLVM bitcode (llgo) under heavy development. When that is ready it should be pretty simple
to use Emscripten on it's output.
So in a way work on that is already under way and much better than targeting asm.js directly since LLVM bitcode can also be used in Chrome's upcoming Native Client or compiled to many differen CPU architectures.

[minux]

we have a exp/ssa package in Go tip, so this might not be that difficult.

tip.golang.org/pkg/exp/ssa/interp

Besides exp/ssa, go/types should be ready for Go 1.1 so a lot of heave lifting for a Go toolchain

is already been done by compiler experts.

[Dave Cheney]

On 19/02/2013, at 21:20, Niklas Schnelle <niklas....@gmail.com> wrote:

> So an asm.js aware engine can execute it as fast as Java or C# while it still runs on every browser.

[citation needed]

[Archos]

That's right, asm.js is a low-level target language for languages like C and C++. It's not designed for compiling languages like CoffeeScript or Gotojs.

[Niklas Schnelle]

http://asmjs.org/spec/latest/
It's completely static typed and ahead of time compiled, so they should be able to just use something like LLVM.
Since there is also no garbage collection and I guess other features will be missing to this should be quite straight forward (as far as developing compilers
can be considered straight forward)

[John Nagle]

On 2/18/2013 9:54 PM, Philipp Schumann wrote:

An easier approach, and one that would execute faster, would be to
run Go-generated x86 code under Google Native Client.

https://developers.google.com/native-client/

They're both Google projects. They should work together.

John Nagle

[Patrick Mylund Nielsen]

Not everyone runs Chrome, or even wants to run NaCl. The point of asm.js is that it targets something that is ubiquitous.

[Archos]

I'd contacted with the designers and these are the answers:

"It's too low-level for languages like CoffeeScript. It works best for languages at a lower level of abstraction like C or C++. Implementing CS at this level would require writing your own garbage collector and JavaScript runtime. Which would be pretty silly since you're implementing on top of JavaScript, which already provides those things.

That said, we intend for asm.js to grow to support higher-level constructs like garbage-collected data, making it suitable for mid-level (but still statically typed) languages like Java and C#. But it would probably still end up being pretty silly to implement a language like CoffeeScript -- which maps directly onto JS -- this way. You'd almost certainly get worse performance than the existing CoffeeScript compiler produces."

Then it would be awesome that it could be suitable for languages Go and Rust.

"The sticking point there is concurrency. But it's definitely worth exploring."

[Ian Davis]

Latest demo of Emscripten and asm.js is UnrealEngine which is over a million lines of C++: http://blog.bitops.com/blog/2013/05/01/unreal-javascript/

Threading is done with web workers apparently but I  have no idea if that was added by hand or if it is automatic from the LLVM bitcode conversion.


Would be nice to see Go -> LLVM -> Emscripten -> asm.js with some concurrency as a proof of concept

[fari...@gmail.com]

It is possible to compile go to LLVM byte code with llgo: https://github.com/axw/llgo

This means it is possible to compile go to asm.js.

[Rasmus Schultz]

For real? That would be bad ass.

Has anyone attempted it yet? Results? :-)

[Richard Musiol]

If you are interested in running Go code in the browser, you may want to take a look at my GopherJS project. It translates Go code directly to fast JavaScript:

https://github.com/neelance/gopherjs

[Rasmus Schultz]

That is pretty cool, though I have been wondering if I think Go is necessarily a great language for front-end development.

Have you built anything substantial on the front-end using Go yet? I'd like to hear what you experience was like.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/0d1vFi7mrnA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Richard Musiol]

I think having back-end and front-end in the same language is an advantage. Also, I really like Go and I see no reason why it would not work well in the front-end domain, since it has functions as first class objects. But you should better ask this question in the GopherJS group ( https://groups.google.com/forum/#!forum/gopherjs ), since the early adopters might give much better feedback than me. I am quite busy with working on GopherJS itself, I only used it for building the playground ( http://neelance.github.io/gopherjs-playground/ ).

[Chris McGee]

I'm interesting in using this on the browser side but I wonder how easy/hard dom manipulation is with this. Is there a set of interfaces for the html dom or alot of magic strings?

Cheers,

Chris

[Rusco]

At least the TodoMVC (based on jquery bindings) is working:

https://github.com/rusco/todomvc

Try it out !
Cheers/Rusco

[Dominik Honnef]

Chris McGee <newt...@gmail.com> writes:

> I'm interesting in using this on the browser side but I wonder how
> easy/hard dom manipulation is with this. Is there a set of interfaces for
> the html dom or alot of magic strings?

I'm currently working on a set of bindings to the DOM API, at
https://github.com/dominikh/go-js-dom – it's not complete yet (because,
as it turns out, the API is huge), but a lot of the common stuff works,
including events.

[Elliott Stoneham]

There are currently at least three Go compilers being built that can generate JavaScript:

1. GopherJS generates it directly;
   
2. TARDISgo generates it indirectly (via Haxe); but
3. llgo should be able to generate actual "asmjs" by processing its output using Emscripten. 

I gave a talk at FOSDEM on Sunday which included this subject. Only the slides are available at the moment, but a video is coming soon.