Anyone interested in this please look at:

https://github.com/inhabitedtype/httpaf

A webserver in native OCaml that's going to beat Node.js (it seems popular cohttp server in OCaml was not cutting it).

I would be really interested about why this is getting downvoted? This seems like a related project, and I was happy to learn about it.

I'm back in the plus. Also cannot imagine someone down voting :-P

not a downvoter, but probably the “going to beat Node” part. an assertion which cannot be proved or refuted, and which is vague but provocative.

edit: actually I became a downvoter just now.

cohttp is not going to beat Node. Compiled code in a reasonably low level language should be able to beat (measures in all resources used, not just response times, but also mem/cpu consumption) an interpreted language for a simple task of responding to network requests. Well, that's at least what I believe, maybe I'm wrong.

this is also a vague but provocative claim. beat Node at what? what's the criteria for success? popularity? performance? security? I don't have a downvote for you, but answering a vague but provocative claim with another vague but provocative claim is not really that helpful in my opinion.

"my language can beat up your language" is like "my dad can beat up your dad."

ReasonML has two compilers -- a compiler that goes to JavaScript, and a compiler that goes to native code (the OCaml compiler, since Reason and OCaml share an AST/etc.) So if you want to use ReasonML with a web server, you have two options:

1) A native web server, or 2) NodeJS.

Because Reason can compile to JS, you can use with Node just like any other compiles-to-JS language. The claim here (which I have no opinion on either way) is that using a particular native OCaml web server with ReasonML is faster than compiling ReasonML to JS and using it with Node.

> that using a particular native OCaml web server with ReasonML is faster than compiling ReasonML to JS and using it with Node.

Faster considering the resources used (mem/cpu). Yups. Exactly that was my claim. Cohttp cannot beat Node, while a natively compiled OCaml server should be able to beat node.

> This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native)

Why not just use the real OCaml/Reason compiler ... ?

bsb-native is not a compiler. It uses ocamlopt for compiling. Bsb-native is a build tool, think of it like make

Reason is supported on every major version of the native OCaml compiler (currently versions 4.02.3 up to 4.06).

I know, hence my question! Why go through bs (which is locked to an old version of OCaml) to distribute executables, when you can use the normal compiler and enjoy the latest improvements?

I don’t mean to ignore your observation - it is valid. Bsb is a build system that works with a specific form of packages. What you suggest could work too. The only (small?) challenge is that people have bsb JS projects, and they aren’t configured for jbuilder/Dune etc. Because of JavaScript’s immense popularity, the largest number of people will start with whatever build tools integrate well with the JavaScript ecosystem and work from there. This plays out quite predictably. Just as an example, the most important thing to web developers is that each Reason input file becomes a commonJS (or es6) module. That allows integrating your Reason React app with existing web apps easily. So since people start with whatever tools integrate well with the JS ecosystem, they then reach for the easiest tool available to adopt native compilation.

I think that configuring jbuilder/etc. can be a point of friction for people coming from bucklescript, so bsb-native provides the same workflow for native compilation.

I once read about a project that was basically Node.js as Reason module. They used the OCaml std lib and wrapped it with a a very Node.js like interface, so you could write native stuff with your Node.js skills.

I think you’re talking about this https://kennetpostigo.github.io/lwt-node/

Yes, exactly :)