bisect_ppx VS reason

Compare bisect_ppx vs reason and see what are their differences.


Code coverage for OCaml and ReScript (by aantron)


Simple, fast & type safe code that leverages the JavaScript & OCaml ecosystems (by reasonml)
Our great sponsors
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
  • SonarQube - Static code analysis for 29 languages.
bisect_ppx reason
1 15
239 9,564
- 0.3%
8.7 2.9
8 days ago 4 months ago
OCaml OCaml
MIT License MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of bisect_ppx. We have used some of these posts to build our list of alternatives and similar projects.
  • Debugging/Profiling/VM library for Ocaml.
    1 project | | 21 Sep 2021
    It's not so clear to me what you want, the following come to mind: - if you want to "inspect the recursive calls" of a recursive function, you may not need any instrumentation: you can turn your function in open-recursion style, and provide a fixpoint combinator that does the inspection (see code below) - if you want to instrument the code globally, one easier-than-most approach is to use a ppx preprocessor to instrument the code (this assumes that the logic you want can be expressed as a slight modification of the user-written code), see ppx_bisect (code-coverage instrumentation) for example.


Posts with mentions or reviews of reason. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-17.
  • Failing to Learn Zig via Advent of Code
    17 projects | | 17 Jan 2022
    OCaml is pretty close already to what you're describing. The OCaml ecosystem fully embraces imperative programming. And if the syntax of OCaml is problematic, then perhaps ReasonML ( is what you're looking for: a curly-braces syntax for OCaml.
  • Bleeter - UI for GTA V's microblogging site built using React and F#
    2 projects | | 31 Dec 2021
    I've not looked at it much myself beyond listening to a talk but if you're interested in Functional+React you may want to look at ReasonML, which is a variant of OCaml. It's written by Jordan Walke, who wrote the first version of React, and has strong React support.
  • Trying Out Generics in Go
    7 projects | | 16 Dec 2021
    I found this closed-mindedness hard to understand -- I don't spend very much conscious thought on the syntax when programming at all -- but for people like you facebook made Reason ML

    Someone should port OCaml to the Go runtime with a good high-level FFI. It could really give the community a boost.

  • Why You Should Learn Functional Programming
    4 projects | | 26 Nov 2021
    These new tools and perspectives empower you to write better programs even when you write in traditional languages. In fact, many modern extensions/frameworks have functional flavours added. See for example ReasonML and typescript. Learning functional programming will give you the necessary building blocks to pick up these frameworks quickly and correctly.
  • It takes a PhD to develop that
    6 projects | | 4 Oct 2021
    You may find Elm, PureScript, or Reason to be of interest.
  • How long did it take you to get good at React?
    2 projects | | 21 Aug 2021
  • Are Dynamic Languages Going to Replace Static Languages? (2003)
    7 projects | | 4 Aug 2021
  • 700k lines of code, 20 years, and one developer: How Dwarf Fortress is built
    4 projects | | 29 Jul 2021
    You're right you are unaware. This is not an insult and I'm not trying to offend you. This is a factual statement. You truly are unaware as you stated yourself, and I can prove it to you.

    First off FRP is actually a term. Functional Reactive Programming. It is 100% a functional paradigm that gasp by DEFINITION cannot be procedural. So you truly didn't know what you were talking about here:

    Second there are many languages/frameworks that use this paradigm. React partially uses this paradigm. But I will list two popular ones that strictly follow it... just note that there are more. Much more.

    Take a look at elm. Elm is a fully functional UI library and language that is 100% pure, functional and has no OOP. Believe it or not ELM is not some toy, it is production ready and actually measurably faster than react. This language is what popularized the FRP pattern which is partially used by React today. See here:

    Note the load time and latency on the mario game. React doing the same thing will be slower.

    Another language is ReasonML. Created by the creator of React, Jordan Walke. Coupled with React, ReasonML is essentially the ideal GUI paradigm that Jordan would recommend everyone to use in the ideal world. However due to the fact that everyone is use to javascript, Jordan instead as a first step, ported FRP concepts over to a language called JSX (essentially JavaScript mixed with html) and is slowly nudging the world in the direction of GUI programming using the functional style:

    Make no mistake the creator, of the most popular GUI framework in the world is a supporter of the pure functional paradigm.

    You're right on the wrapper part though. Assembly language is essentially a procedural language so every single thing that exists on top of it, is a wrapper.

  • Is there a statically typed functional programming language that doesn't take purity so seriously?
    7 projects | | 1 Jun 2021
    And if you don't care for the syntax, you can use Reason instead, which is a JS-like syntax alternative that sits atop the OCaml compiler, so you get the same features but in the more familiar trappings of a curly-brace language.
    7 projects | | 1 Jun 2021
    Now the real Reason site primarily mentions using js_of_ocaml for JS compilation instead of endorsing bucklescript, though maybe when Melange's changes and updates* to bucklescript stabilise it'll switch over to suggesting that. jsoo is good at what it does but it uses some OCaml black magic that creates some awful error messages; plus it converts the intermediate AST representation to JS and creates a giant unreadable blob. BuckleScript (and now Melange) take over compilation a bit earlier, giving you more readable output and allowing some things to be done more smoothly.

What are some alternatives?

When comparing bisect_ppx and reason you can also consider the following projects:

purescript - A strongly-typed language that compiles to JavaScript

rescript-compiler - The compiler for ReScript.

js_of_ocaml - Compiler from OCaml to Javascript.

ocamlformat - Auto-formatter for OCaml code

Elm - Compiler for Elm, a functional language for reliable webapps.

refterm - Reference monospace terminal renderer

melange - A mixture of tooling combined to produce JavaScript from OCaml & Reason

pydantic - Data parsing and validation using Python type hints

Statsd - Daemon for easy but powerful stats aggregation

dune - A composable build system for OCaml.

ts-auto-guard - Generate type guard functions from TypeScript interfaces

sqlite3-ocaml - OCaml bindings to the SQLite3 database