Hello wasm-pack

Re:Hello wasm-pack by themihai on Thursday April 19, 2018 @08:26AM (#16875265)

Elm was designed to be transpiled into javascript just like CoffeScript so let's put it aside for a moment. WASM is work in progress so I'm sure that if people care enough they can find solutions for such specific issues(i.e. seems that VM languages have their own set of issues). There is a GC proposal so managed languages will benefit a lot(i.e. smaller runtime).

JS is a high level language. I don't see many people compiling to managed languages outside of the browser. Wonder why is that? Few target JVM...but I don't see many(if any) compiling to Java, C#, Ruby or Lua or PHP. I've never seen anyone compiling JavaScript either unless they had to run it in a browser. This should tell you how good JS is when it has to compete on merit as compiler target.

[ Parent | on HN ]

Re:Hello wasm-pack by fulafel on Thursday April 19, 2018 @09:20AM (#16875653)

Elm semantics is very far from JS - it's a kind of Haskell-lite. The tooling and diagnostics are very much custom and don't rely on JS developer tools or source maps. (Also, "transpile" is just another word for "compile")

[ Parent | on HN ]

Re:Hello wasm-pack by themihai on Thursday April 19, 2018 @12:03PM (#16877006)

Do you mean that Elm was not designed considering JS as its compilation target? Is Elm used anywhere else than the web browser? Why nobody compiles to JS outside the web browser if it's such a good compilation target?

>> Also, "transpile" is just another word for "compile"

Well, I prefer to use the "transpile" term when the target is a high level language.

JavaScript is a high level language. It seems some smart folks decided that a new "language/IR" is needed (wasm) so that people can use other languages on the web. Now let's make this new IR a first class citizen on the web.

[ Parent | on HN ]

Re:Hello wasm-pack by fulafel on Thursday April 19, 2018 @01:01PM (#16877610)

I'm sure Elm design considered JS, but I'm also sure that if WebAssembly had been available when Elm was designed, it would still have targeted JS rather than WebAssembly. Same goes for ClojureScript.

WebAssembly is a refinement of asm.js, which started as a mechnism to enable C/C++ code to run in browsers. Other, managed languages aren't forced to go the asm.js route because their semantics aren't tightly married to a byte addressable, untyped program heap.

[ Parent | on HN ]

Re:Hello wasm-pack by themihai on Thursday April 19, 2018 @04:15PM (#16879706)

What exactly makes JavaScript a better target for languages such Elm (apart from GC and DOM access which are supposed to be implemented sooner or later) ? You realise that JavaScript itself is also compiled/transpiled by the browser engine(i.e. v8) before it executes, right?

[ Parent | on HN ]

Re:Hello wasm-pack by fulafel on Friday April 20, 2018 @01:15AM (#16882306)

Let me count the ways:

- code size - a runtime for a managed language is much bigger if you have to reimplement & ship the primitives you get from the JS platform.

- implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

- poor cross-browser development tooling support to have a good debugging experience

- GC implementation complexity and performance - firstly, there is no GC support currently and no timeline about when/if something materalizes. The current "future GC" support in webassembly[1] doesn't provide a GC implemnetation, just hooks to peacefully coexist with JS GC.

- JS interop

- browser support

Now, it may be that some of these get solved eventually - but they would all have to be solved, with high quality solutions, to beat JS as a managed language compile target.

[1] https://github.com/WebAssembly/reference-types/blob/master/p...

[ Parent | on HN ]

Re:Hello wasm-pack by themihai on Sunday April 22, 2018 @01:11PM (#16897144)

>> - implementation complexity: a LLVM-webassembly-toolchain along with your own GC is much harder and more work than a JS backend, and would need to have a rather good payoff to be worth investing in.

I strongly disagree. Wonder why no language(managed or unmanaged languages) designer uses this gem named JavaScript as compile target?(web stuff excluded)

It seems your whole argument revolves around the fact that JS has better support than WASM in browser. We already know this. WASM is a work in progress. It's not ready yet for prime time. This year we will get some managed languages compiled to WASM. Next year we might get GC. I believe in some distant future javascript will be compiled to wasm either by the client or by the browser itself(for backward compatibility). JavaScript is JIT-ed in the browser anyway.

[ Parent | on HN ]