CIcies·Jan 12, 2022
I rather work with OCaml/httpaf[0] than with JS/express or what have you.
[0]: https://github.com/inhabitedtype/httpaf
In From TypeScript to ReScriptinhabitedtype
httpaf
OCaml2017–2022
inhabitedtype / httpaf
httpaf
A high performance, memory efficient, and scalable web server written in OCaml
6Distinct people
12Mentions
0Explicit recommenders
539GitHub stars
What to know before exploring
What it is
A high performance, memory efficient, and scalable web server written in OCaml
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- anmonteiro/ocaml-h2 · linked in 2 of the same discussions
- mirage/ocaml-cohttp · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year12 dated mentions
Observed mentions: 2017-08-28 04:10:51 UTC to 2022-01-12 12:23:55 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
12 sourcesAn example of a concrete usage of parser combinators and their performance: OCaml's http/af library [1] is a web server that uses parser combinators to implement HTTP 1.1. As for the performance, it's in the ballpark of Go's net/http and Rust's hyper [2]. There's also h2 [3] that implements HTTP 2. They are based on Angstrom [4], which started as a direct port of attoparsec [5], cited in the article. It's great to see all the cross-pollination happening in that space!
[1]: https://github.com/inhabitedtype/httpaf
[2]: https://github.com/ocaml-multicore/retro-httpaf-bench/pull/1...
[3]: https://github.com/anmonteiro/ocaml-h2
[4]: https://github.com/inhabitedtype/angstrom
[5]: https://github.com/haskell/attoparsec
In Parser Combinators in HaskellThanks for chiming in!
Sadly cohttp is (or was) performing so bad that it is kind of at odds with using it on a unikernel.
This one is quite a bit faster:
https://github.com/inhabitedtype/httpaf
In The RustyHermit UnikernelI wonder how this will impact the performance of libs like http/af[0] (which is event-based, so it should not make much/any difference, right?).
Also: should we expect OCaml entries to show up higher in TechEmpower style benchmarks in the near future?
[0]: https://github.com/inhabitedtype/httpaf
In Multicore OCaml: October 2020You can compile to native and use the whole OCaml ecosystem over there (in stead of the NPM ecosystem when doing client-side or Node-based-server-side) to write your apps.
For instance this fast OCaml http server: https://github.com/inhabitedtype/httpaf
And you can even share types between client and server :)
In Multicore OCaml: March 2020 updateThere is some good work going on for the lower level pieces:
https://github.com/anmonteiro/ocaml-h2 - HTTP2 stack
https://github.com/inhabitedtype/httpaf - HTTP stack
For micro-frameworks there are a few options available like
https://github.com/rgrinberg/opium
https://github.com/ostera/httpkit
There are some scattered pieces in the ecosystem for routing, sessions etc but i agree that compared to Python, JS, etc the ecosystem might not look as cohesive or expansive for web applications. So there should definitely be room to have new solutions in this space
In OCaml 4.08Being 'single-core only' is not that much of a problem if you're coming from Python and immediately seeing a huge performance boost compiling to Go-style static native binaries, I think? People immediately jump on the 'single-core' thing with OCaml, but can you explain what exactly it is that you're trying to do with multicore that's not covered by a concurrency library like Lwt or a multi-processing library like Async Parallel?
Re: database drivers–which one are you looking for? MSSQL ( https://discuss.ocaml.org/t/ann-first-release-of-mssql/3242 )? Or Postgres ( http://mmottl.github.io/postgresql-ocaml/ )? Or SQLite ( https://github.com/mmottl/sqlite3-ocaml )?
Re: web frameworks–Eliom ( https://ocsigen.org/eliom/6.6/manual/intro ) is one of the most powerful isomorphic web frameworks. Or do you want to spin up a quick JSON API server wi
Read the rest
th Cohttp ( https://github.com/mirage/ocaml-cohttp )? Or dig into a high-performance, lower-level server ( https://github.com/inhabitedtype/httpaf )?
Or you want a Kafka client ( https://opam.ocaml.org/packages/kafka/ )?
Or maybe you can just take advantage of BuckleScript's high-fidelity approach to transpiling OCaml to JavaScript, and write some bindings to take advantage of basically everything in the npm ecosystem?
Sure, not every OCaml library is battle-tested, but I think that's not a good reason to immediately discount it. I didn't tell StavrosK to immediately commit to and rewrite everything in OCaml, I said he might find it interesting. Even with Go, Rust, and TypeScript as options, because:
- Not everyone is satisfied with Go's type system or its model of error handling, or its low ceiling for abstraction.
- Not everyone is satisfied with Rust's overall newness and potential compiler and library bugs, its lack of GC and the subsequent having to deal with borrow checking, or its slow compile times.
- Not everyone is satisfied with trying to model the dynamic complexity of JavaScript in a new, explicitly unsound type system. And it's no secret that the BuckleScript compiler can run rings around tsc for compile speed (not even mentioning the more powerful and battle-tested OCaml language).
Reason is merely a new syntax on OCaml. You can use BuckleScript (BS) to compile to JS, or not use BS to compile to native.
There exists a fast http server in native OCaml:
https://github.com/inhabitedtype/httpaf
In Show HN: Fnm – Fast and simple Node.js version manager built in ReasonMLThere is a reason-vue project (https://github.com/JasonShin/reason-vue), but from my memories with Vue it is not a great fit for a statically typed language because a lot in Vue is "stringly typed" (which means that it is untyped and basically works by using the same/right string in your code, opening a huge opportunity for typo-bugs that a compiler cannot find).
You may want to look into this project which is an alternative to the React ecosystem: an implementation of the Elm architecture in OCaml/BuckleScript (and thus Reason).
https://github.com/OvermindDL1/bucklescript-tea
> What about server-side with Node?
Possible with Reason, yet compilation to native is also possible from Reason... This allows one to use really fast all-OCaml libraries. Like this HTTP server:
https://github.com/inhabitedtype/httpaf
In Relit: Typed Literal Macros for Reason>build:
Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ]
It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly.
>I'm saying that you need to provide evidence that OCaml is faster
>"OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive).
Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like
Read the rest
this:
https://github.com/inhabitedtype/httpaf/blob/master/lib/pars...
instead of this:
https://github.com/valyala/fasthttp/blob/master/header.go
(and this is only a header)
and let the compiler do all the dirty work.
> with a dozen `|>` operators
how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway.
>Something as common as JSON should be dead simple
It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?
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).
In Deploying a ReasonML React app with DockerBut cohttp is slow. See https://github.com/mirage/ocaml-cohttp/issues/328 and https://github.com/inhabitedtype/httpaf
In BuckleScript: An OCaml to JavaScript compiler