6 ms·

Compile OCaml to JavaScript, Run on Node

77 points by antouank 11y ago

r-cyr 11y ago
What I REALLY want to know is... can it run "flow" (https://github.com/facebook/flow https://github.com/facebook/flow). Because it's very useful yet painful to install... And I don't even know if it works on Windows.
- tel 11y ago
  For some reason I remember there being a web version of flow that was being compiled through js_of_ocaml. Maybe I'm confusing this with another project, though.
  - e_d_g_a_r 11y ago
    I'm pretty sure the parser could be compiled with js_of_ocaml, but not sure if everything can be. Would need to look...
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
mjt0229 11y ago
The comments on the blog post are hilarious to me. "And why do you need type safety? Because you are used to?" Er. Well, if you like driving a car with no seatbelts, crumple zone, or airbags, I guess that's fine with me. But when I get in a car, I buckle up.
- kod 11y ago
  That's a somewhat poor analogy, since airbags etc don't prevent you from doing certain driving maneuvers. Static type systems prevent you from expressing certain programs (I think this is a good thing, but not everyone does). A better analogy would be antilock brakes or understeer - safer but prevents you from doing certain things.
  - mjt0229 11y ago
    Agreed.
  - to3m 11y ago
    A better analogy would be driving a car - it's not a tangerine.
  - ch 11y ago
    More like it allows you to accelerate with a pedal on the floor rather than by pulling a string attached directly to the throttle. No loss of flexibility, but you put some trust in the vehicle that you would otherwise have to manage yourself.
  - ybx 11y ago
    A better analogy is the one that's twisted to fit my narrative. (both you and the parent comment are kinda doing this)
- sgeisenh 11y ago
  Once you've experienced the joys of parametricity, you can never go back!
- rlander 11y ago
  Yup, came here to say that! The "If you don't like JavaScript, just use CoffeeScript like everyone else! What's wrong with you?" reaction made me laugh.
- junke 11y ago
  The static types protect you from undesired runtime behaviors with respect to OCaml's runtime semantics, but what about Javascript's one? This is better than nothing, sure, because your code is first checked in OCaml but once the code is running, it does it according to Javascript rules. I imagine there could be subtle bugs introduced during this process (e.g. your OCaml code manipulate integers, but Javascript has numbers, a.k.a. double floats, as far as I know).
  - Drup 11y ago
    This is no different than trusting the processor for running the emmited assembly according to the model you have for what assembly is supposed to do. Here, the compiler emits (a subset of) javascript which are assumed to have a semantics, and we trust the browser engine to execute it according to the semantic. Of course we don't assume the semantic of javascript to be sane, we just assume it follows the spec (and we emit accordingly).
  - rlander 11y ago
    I see your point, but that's like arguing compiled Haskell code is unsafe, since Haskell has type erasure. Any code generation machinery is subject to subtle bugs and especially so the flesh and bones kind ;)
  - e_d_g_a_r 11y ago
    I haven't had a single problem at all and I've wrapped even the most sensitive stuff like the event emitter itself and streams.
hbbio 11y ago
Glad to see OCaml gaining steam. This is quite close to another project written in OCaml: Opa ( http://opalang.org http://opalang.org ). Opa differs in that it is a new language though, but the compiler is written in OCaml and compiles the Opa language to JavaScript (using by default Node.js and MongoDB). Compared to this project, Opa provides much more automation (ORM except it's neither Object nor Relational, slicing i.e. separation of client and server code, etc.). Disclaimer: I'm the creator of Opa.
- Drup 11y ago
  It's a bad comparison though. The real equivalent of opa in the OCaml ecosystem is eliom. :) (Also, isn't opa a bit, you know, dead ?)
  - hbbio 11y ago
    Opa is as dead as a project we use daily.
    - zem 11y ago
      good to hear!
murbard2 11y ago
You can also run eliom (http://ocsigen.org/eliom/ http://ocsigen.org/eliom/) which offers reactive DOM elements. Not as seamless as Meteor, but you get something pretty close with the benefits of type safety, down to the HTML you generate.
- Drup 11y ago
  As someone working on eliom, I would really like to hear you on the areas where we can improve seamless-ness. :)
  - murbard2 11y ago
    To be honest, I haven't used it seriously enough to give you the good answer this deserves. A friend of mine evaluated it for his own need and went with Meteor citing that reason (plus ease of hiring for js). I've gotten a similar feel looking at the code samples. Take for example this basic example: {server{ let get_data_forum forumid = lwt messages = Db.get_messages forumid in let default = {'a option{ try Some (Eliom_cscache.find_if_ready %forumcache %forumid) with _ -> None }} in Lwt.return (SharedReactiveData.RList.make ~default messages) let get_data_forum_rpc = server_function Json.t<int> (Eba_session.Opt.connected_rpc (fun userid_o forumid -> get_data_forum forumid)) }} {client{ let get_data_forum forumid = %get_data_forum_rpc forumid }} This feels awfully verbose for what it does...
tdurden 11y ago
The amount of "compile to JavaScript" tools is impressive https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

77 points by antouank 11y ago

r-cyr 11y ago

What I REALLY want to know is... can it run "flow" (https://github.com/facebook/flow https://github.com/facebook/flow). Because it's very useful yet painful to install... And I don't even know if it works on Windows.

tel 11y ago
For some reason I remember there being a web version of flow that was being compiled through js_of_ocaml. Maybe I'm confusing this with another project, though.
- e_d_g_a_r 11y ago
  I'm pretty sure the parser could be compiled with js_of_ocaml, but not sure if everything can be. Would need to look...
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]

mjt0229 11y ago

The comments on the blog post are hilarious to me. "And why do you need type safety? Because you are used to?" Er. Well, if you like driving a car with no seatbelts, crumple zone, or airbags, I guess that's fine with me. But when I get in a car, I buckle up.

kod 11y ago
That's a somewhat poor analogy, since airbags etc don't prevent you from doing certain driving maneuvers. Static type systems prevent you from expressing certain programs (I think this is a good thing, but not everyone does). A better analogy would be antilock brakes or understeer - safer but prevents you from doing certain things.
- mjt0229 11y ago
  Agreed.
- to3m 11y ago
  A better analogy would be driving a car - it's not a tangerine.
- ch 11y ago
  More like it allows you to accelerate with a pedal on the floor rather than by pulling a string attached directly to the throttle. No loss of flexibility, but you put some trust in the vehicle that you would otherwise have to manage yourself.
- ybx 11y ago
  A better analogy is the one that's twisted to fit my narrative. (both you and the parent comment are kinda doing this)
sgeisenh 11y ago
Once you've experienced the joys of parametricity, you can never go back!
rlander 11y ago
Yup, came here to say that! The "If you don't like JavaScript, just use CoffeeScript like everyone else! What's wrong with you?" reaction made me laugh.
junke 11y ago
The static types protect you from undesired runtime behaviors with respect to OCaml's runtime semantics, but what about Javascript's one? This is better than nothing, sure, because your code is first checked in OCaml but once the code is running, it does it according to Javascript rules. I imagine there could be subtle bugs introduced during this process (e.g. your OCaml code manipulate integers, but Javascript has numbers, a.k.a. double floats, as far as I know).
- Drup 11y ago
  This is no different than trusting the processor for running the emmited assembly according to the model you have for what assembly is supposed to do. Here, the compiler emits (a subset of) javascript which are assumed to have a semantics, and we trust the browser engine to execute it according to the semantic. Of course we don't assume the semantic of javascript to be sane, we just assume it follows the spec (and we emit accordingly).
- rlander 11y ago
  I see your point, but that's like arguing compiled Haskell code is unsafe, since Haskell has type erasure. Any code generation machinery is subject to subtle bugs and especially so the flesh and bones kind ;)
- e_d_g_a_r 11y ago
  I haven't had a single problem at all and I've wrapped even the most sensitive stuff like the event emitter itself and streams.

hbbio 11y ago

Glad to see OCaml gaining steam. This is quite close to another project written in OCaml: Opa ( http://opalang.org http://opalang.org ). Opa differs in that it is a new language though, but the compiler is written in OCaml and compiles the Opa language to JavaScript (using by default Node.js and MongoDB). Compared to this project, Opa provides much more automation (ORM except it's neither Object nor Relational, slicing i.e. separation of client and server code, etc.). Disclaimer: I'm the creator of Opa.

Drup 11y ago
It's a bad comparison though. The real equivalent of opa in the OCaml ecosystem is eliom. :) (Also, isn't opa a bit, you know, dead ?)
- hbbio 11y ago
  Opa is as dead as a project we use daily.
  - zem 11y ago
    good to hear!

murbard2 11y ago

You can also run eliom (http://ocsigen.org/eliom/ http://ocsigen.org/eliom/) which offers reactive DOM elements. Not as seamless as Meteor, but you get something pretty close with the benefits of type safety, down to the HTML you generate.

Drup 11y ago
As someone working on eliom, I would really like to hear you on the areas where we can improve seamless-ness. :)
- murbard2 11y ago
  To be honest, I haven't used it seriously enough to give you the good answer this deserves. A friend of mine evaluated it for his own need and went with Meteor citing that reason (plus ease of hiring for js). I've gotten a similar feel looking at the code samples. Take for example this basic example: {server{ let get_data_forum forumid = lwt messages = Db.get_messages forumid in let default = {'a option{ try Some (Eliom_cscache.find_if_ready %forumcache %forumid) with _ -> None }} in Lwt.return (SharedReactiveData.RList.make ~default messages) let get_data_forum_rpc = server_function Json.t<int> (Eba_session.Opt.connected_rpc (fun userid_o forumid -> get_data_forum forumid)) }} {client{ let get_data_forum forumid = %get_data_forum_rpc forumid }} This feels awfully verbose for what it does...

tdurden 11y ago

The amount of "compile to JavaScript" tools is impressive https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js https://github.com/jashkenas/coffeescript/wiki/list-of-langu...