4 ms·

Well, Rust can compile to asm.js or wasm, too. Might still be rough around the edges, but it will improve soon enough.

chrismorgan 10y ago
Rust compilation is slow, and the compilation target opaque. BuckleScript is fast, and compiles to readable JavaScript. Please don’t just go spouting that Rust is the answer to everything; it’s not. It’s also not always relevant in a discussion. (I say this as someone who is lauding Rust at every turn and who has been using it seriously for years and who is looking forward to a solid wasm target and ecosystem.)
- dochtman 10y ago
  Sorry, my post maybe came off as more negative than I intended, but the downvotes seem a bit harsh. To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. Readable JavaScript is not as important as long as we have source maps, which WebASM was designed to take into account. Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript, which IMO is worth the longer compile cycles. I think Rust is relevant because Ocaml and Rust share a lot of heritage (indeed, I think Ocaml was one of the most influential languages in the Rust design), so I think that makes it relevant in this discussion.
  - sjrd 10y ago
    The problem with wasm right now is that it gives you very little in terms of interoperability with JavaScript. You simply cannot manipulate JS objects (including DOM objects) from wasm. Compiling a language like BuckleScript to wasm is therefore not possible at the moment, simply because the interop features of BuckleScript cannot be encoded in wasm. Besides, there are other difficulties: wasm doesn't have any kind of managed heap at the moment, which means that compiling a managed language to wasm requires to embed an entire GC in your production code! It's much better to take advantage of all the VM features offered to JS, like a GC, when compiling a managed language to the Web platform.
  - grayrest 10y ago
    > To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. It's behind a flag in a couple browsers. Even with a flag, if you're going to actually do anything with the DOM, you're going to be shipping a js support library and calling into it. Using something that works now has value, particularly when you could get wasm in the future off the same code if anybody writes an OCaml wasm backend. > Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript Bucklescript adds asm.js type hints (but not the use strings) to the js output and does a fair number of optimization passes. Aside from reducing parse time, going from its current output to wasm is unlikely to pick up much in the way of perf. I'm actually not even convinced that wasm is going to be that much faster for load+parse over an optimized js payload because asm.js/wasm have to ship the runtime (allocator, stdlib, etc) while js just has to ship the code. > Readable JavaScript is not as important as long as we have source maps I write Clojurescript full time, which has source map support. I completely disagree with this statement. > Ocaml and Rust share a lot of heritage Rust was bootstrapped off an OCaml compiler. I like Rust and advocate for it but bringing up another compile-to-js language, particularly one as nascent as Rust doesn't really have anything to do with the merits or drawbacks of Bucklescript.
- wereHamster 10y ago
  > BuckleScript is fast, and compiles to readable JavaScript. What is the obsession with having readable JavaScript? In the debugger (devtools) I don't want to step through the low-level assembler instructions (JavaScript), I want to remain in the high-level language where reasoning about the behaviour is actually possible. We have sourcemaps for a reason, make use of it!
  - yawaramin 10y ago
    Sourcemaps aren't always possible with some workflows e.g. transpiling then bundling. Plus, readable JS is a huge productivity boost because it lets people transition away from JS into OCaml while still understanding their JS output every step of the way.
  - eru 10y ago
    Readable JavaScript or not might not make a difference in the long run, but it sure helps adoption when a single person on a team can start using Bucklescript without having the pure JavaScripters hate her for it (or even having to know she's not writing her js by hand).
marcosscriven 10y ago
I don't understand why your comment was downvoted - it does seem to be relevant to the topic of compiling a typed language to Javascript.
- sjrd 10y ago
  If that comment were relevant, then so would 100 other similar comments mentioning another typed language that compiles to JS. Do you really want to drown the interesting HN comments in a heap of "hey, my favorite language also compiles to JS" kind of comments?

Rust compilation is slow, and the compilation target opaque. BuckleScript is fast, and compiles to readable JavaScript. Please don’t just go spouting that Rust is the answer to everything; it’s not. It’s also not always relevant in a discussion. (I say this as someone who is lauding Rust at every turn and who has been using it seriously for years and who is looking forward to a solid wasm target and ecosystem.)

dochtman 10y ago
Sorry, my post maybe came off as more negative than I intended, but the downvotes seem a bit harsh. To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. Readable JavaScript is not as important as long as we have source maps, which WebASM was designed to take into account. Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript, which IMO is worth the longer compile cycles. I think Rust is relevant because Ocaml and Rust share a lot of heritage (indeed, I think Ocaml was one of the most influential languages in the Rust design), so I think that makes it relevant in this discussion.
- sjrd 10y ago
  The problem with wasm right now is that it gives you very little in terms of interoperability with JavaScript. You simply cannot manipulate JS objects (including DOM objects) from wasm. Compiling a language like BuckleScript to wasm is therefore not possible at the moment, simply because the interop features of BuckleScript cannot be encoded in wasm. Besides, there are other difficulties: wasm doesn't have any kind of managed heap at the moment, which means that compiling a managed language to wasm requires to embed an entire GC in your production code! It's much better to take advantage of all the VM features offered to JS, like a GC, when compiling a managed language to the Web platform.
- grayrest 10y ago
  > To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned. It's behind a flag in a couple browsers. Even with a flag, if you're going to actually do anything with the DOM, you're going to be shipping a js support library and calling into it. Using something that works now has value, particularly when you could get wasm in the future off the same code if anybody writes an OCaml wasm backend. > Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript Bucklescript adds asm.js type hints (but not the use strings) to the js output and does a fair number of optimization passes. Aside from reducing parse time, going from its current output to wasm is unlikely to pick up much in the way of perf. I'm actually not even convinced that wasm is going to be that much faster for load+parse over an optimized js payload because asm.js/wasm have to ship the runtime (allocator, stdlib, etc) while js just has to ship the code. > Readable JavaScript is not as important as long as we have source maps I write Clojurescript full time, which has source map support. I completely disagree with this statement. > Ocaml and Rust share a lot of heritage Rust was bootstrapped off an OCaml compiler. I like Rust and advocate for it but bringing up another compile-to-js language, particularly one as nascent as Rust doesn't really have anything to do with the merits or drawbacks of Bucklescript.
wereHamster 10y ago
> BuckleScript is fast, and compiles to readable JavaScript. What is the obsession with having readable JavaScript? In the debugger (devtools) I don't want to step through the low-level assembler instructions (JavaScript), I want to remain in the high-level language where reasoning about the behaviour is actually possible. We have sourcemaps for a reason, make use of it!
- yawaramin 10y ago
  Sourcemaps aren't always possible with some workflows e.g. transpiling then bundling. Plus, readable JS is a huge productivity boost because it lets people transition away from JS into OCaml while still understanding their JS output every step of the way.
- eru 10y ago
  Readable JavaScript or not might not make a difference in the long run, but it sure helps adoption when a single person on a team can start using Bucklescript without having the pure JavaScripters hate her for it (or even having to know she's not writing her js by hand).

marcosscriven 10y ago

I don't understand why your comment was downvoted - it does seem to be relevant to the topic of compiling a typed language to Javascript.

sjrd 10y ago
If that comment were relevant, then so would 100 other similar comments mentioning another typed language that compiles to JS. Do you really want to drown the interesting HN comments in a heap of "hey, my favorite language also compiles to JS" kind of comments?