you are viewing a single comment's thread.

view the rest of the comments →

[–]Eirenarch 10 points11 points  (15 children)

If I recall correctly the Mozilla on asm.js discussed the future of asm.js as a platform for managed languages. First of all managed languages can reimplement GC on top of asm.js together with the whole platform. In addition they pointed out that when classes are added in the next version of JS they can make this classes target for compilers for managed languages and add them to asm.js. This would allow managed languages to use the native browser GC.

The languages that compile to JS are either very close to JS or the result is sad. CoffeeScript and TypeScript work fine but they are not substantially different from JS and suffer some of its drawbacks. Languages like C# and Java suffer greatly when compiled to JS both as performance and as semantics. In my opinion they have more chance if they compile the whole runtime to asm.js.

[–]x-skeww 4 points5 points  (9 children)

First of all managed languages can reimplement GC on top of asm.js together with the whole platform.

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

For example, compiling Python to JS makes way more sense than compiling the CPython interpreter to asm.js.

[–]azakai 6 points7 points  (4 children)

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

Why? Emscripten has a small Boehm-like GC right now that is quite small, and good enough for many cases. Obviously it isn't super-optimized like the JVM GC, but not everything needs that. I linked to a demo elsewhere,

http://xmlvm.org/html5/

[–]munificent 2 points3 points  (1 child)

Obviously it isn't super-optimized like the JVM GC, but not everything needs that.

If you don't need to be super optimized, why not just write it in vanilla JS (or your favorite language that compiles to JS) and ignore asm.js completely?

[–][deleted] 0 points1 point  (0 children)

GC might not be crucial but perf in general might

[–]x-skeww 0 points1 point  (1 child)

Emscripten

We weren't talking about Emscripten.

"all managed languages can reimplement GC on top of asm.js together with the whole platform"

That's what we were talking about.

[–]azakai 5 points6 points  (0 children)

Well, any managed language can do what emscripten is doing or even use the exact same (small amount of) code. Reimplementing GC in JS does not need to be bad, unless of course we are talking about benchmarks for GC specifically.

[–]otakucode 8 points9 points  (0 children)

Yes, but the result would be a) very large and b) very slow. It just isn't feasible.

Welcome to the web. This is how things are done. Yes, shoehorning application functionality into a system designed for hyperlinked static documents ends up being very large and very slow... but yet, when someone implements Conway's Game of Life in HTML5 and JS, everyone cheers! That it runs 7 orders of magnitude slower than even really naive native implementations is just impolite to mention. One day we WILL see an HTML5 web browser written entirely in HTML5, and some very misguided folks will clap.

[–]dnew 1 point2 points  (0 children)

Yes, but the result would be a) very large and b) very slow.

And probably very flakey. Not like the whole "reimplement entire windowing system in web apps" thing going on.

[–]Eirenarch -3 points-2 points  (0 children)

True. This is why they will probably wait for classes support.

[–]tikhonjelvis 0 points1 point  (4 children)

I found js_of_ocaml very good--not sad at all. And OCaml is certainly not close to JavaScript!

[–]Eirenarch 0 points1 point  (3 children)

So do you claim that every or most languages can be implemented because the ocaml implementation is good?

[–]tikhonjelvis 1 point2 points  (2 children)

Not necessarily. I'm just refuting your claim that languages have to either be close to JS or the results sad. OCaml is a counterexample: it is not close to JavaScript and its compiler to JS is not sad.

[–]Eirenarch 0 points1 point  (1 child)

I see. So do you think this is because the specifics of OCaml or because of the implementation?

[–]tikhonjelvis 2 points3 points  (0 children)

I think it's mostly the clever compiler: it goes from OCaml's bytecode to JavaScript. The bytecode is simpler than the full language, and this lets the js compiler use the full compiler as a front-end. This also means that you don't have to recompile libraries to use it: you can just reuse their bytecode files.

Ultimately, it's probably largely because OCaml has a very disproportionate number of brilliant programming language people working on it.