P-p-e-w·Jan 14, 2026
Like this: https://github.com/nbp/holyjit
In Servo 2025 Statsnbp
holyjit
Rust2017–2026
nbp / holyjit
holyjit
Generic purpose Just-In-time compiler for Rust.
13Distinct people
15Mentions
0Explicit recommenders
1.6KGitHub stars
What to know before exploring
What it is
Generic purpose Just-In-time compiler for Rust.
GitHub
Where it is used
No documented product use was verified in the last source check.
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
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 year15 dated mentions
Observed mentions: 2017-10-20 12:47:31 UTC to 2026-01-14 23:56:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
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 | 9 | 0 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
15 sources> There's already a JIT for JS coded in Rust:
To clarify: it's a proof of concept, not a full JIT for JS. If you want to follow that project, it lives here: https://github.com/nbp/holyjit.
In The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70That's not entirely the case - there's definitely research / work being done in this area.
https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new...
https://github.com/nbp/holyjit
In Goro – An implementation of PHP written in GoWell, there is the ability to write something along the lines of https://github.com/nbp/holyjit :)
In Mozilla Project Fusion: Tor Integration into FirefoxNot for long... This could make rust rewrite feasible https://github.com/nbp/holyjit
In Xray – An experimental next-generation Electron-based text editorHolyJit – Generic Purpose Just-In-Time Compiler for Rust
23 points · Open discussionTotally agree. The thing with LuaJIT or more appropriately stock Lua is that the VM is small enough to include in your project directly. If Vec and String were exposed to Lua first class construct, we would be a long way there.
The two most mature, well-designed languages in the Rust world are Gluon [1] and Dyon [2]
I believe there is a _great_ opportunity for something like Terra [3] but woven into Rust. Perhaps with the same type of compiler plugin that enabled HolyJIT [4]
The grail is having both a GC and an ownership based gc-free lower level all in the same language. Start dynamic, harden to static and sprinkle in properties.
As a side note, I have been thinking about how to bolt ownership onto a dynamic language and then I learned about Snowflake [5]. I think it would be totally doable to bolt ownership onto Java using annotations
Read the rest
and AoT subsets of a program, completely escaping the garbage collector. This would be like Terra++
[1] https://github.com/gluon-lang/gluon
[2] https://github.com/PistonDevelopers/dyon
[3] http://terralang.org/
[4] https://github.com/nbp/holyjit
[5] https://www.microsoft.com/en-us/research/publication/project...
This is amazing! Write a regular old interpreter in a fully featured language, then just wrap it in a macro and poof you magically have a jit that will compile and execute your interpreted code on the fly.
Seriously. Look at the example for brainfuck [0], it's less than 70 lines of completely normal interpreter loop, including a one-line macro on the top. What the heck.
[0]: https://github.com/nbp/holyjit/blob/master/examples/brainfuc...
In HolyJit: A New HopeI'm truly sorry that GitHub is blocked where you work.
Here's the pitch, taken from the repo's README [1]:
1) holyjit aims to be easy:
> As a user, this implies that to inline a function in JIT compiled code, one just need to annotate it with the jit! macro.
jit!{
fn eval(script: &Script, args: &[Value]) -> Result<Value, Error>
= eval_impl
in script.as_ref()
}
fn eval_impl(script: &Script, args: &[Value]) -> Result<Value, Error> {
// ...
// ... A few hundred lines or ordinary Rust code later ...
// ...
}
fn main() {
let script = ...;
let args = ...;
// Call it as any ordinary function.
let res = eval(&script, &args);
println!("Result: {}", res);
}
> Thus, you basically have to write an interpreter, and annotate it properly t
Read the rest
o teach the JIT compiler what can be optimized by the compiler.
> No assembly knowledge is required to start instrumenting your code to make
it available to the JIT compiler set of known functions.
2) holyjit aims to be safe:
> Security issues from JIT compilers are coming from:
> * Duplication of the runtime into a set of MacroAssembler functions.
> * Correctness of the compiler optimization.
> As HolyJiy extends the Rust compiler to extract the effective knowledge of the compiler, there is no more risk of having correctness issues caused by the duplication of code.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.
3) holyjit aims to be fast
> Fast is a tricky question when dealing with a JIT compiler, as the cost of the compilation is part of the equation.
> HolyJit aims at reducing the start-up time, based on annotation made out of macros, to guide the early tiers of the compilers for unrolling loops and generating inline caches.
> For final compilation tiers, it uses special types/traits to wrap the data in order to instrument and monitor the values which are being used, such that guard can later be converted into constraints.
> Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.
> As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers. Thus leaving less bugs for you to find out.
[1]: https://github.com/nbp/holyjit/blob/master/README.md
Rustc does, but it doesn't appear to me that holyjit does, that is https://github.com/nbp/holyjit/blob/master/lib/src/compile.r... and https://github.com/nbp/holyjit/blob/master/lib/src/lib.rs#L1...
Basically, it seems (and I haven't fully digested the code yet) that it uses https://crates.io/crates/dynasmrt for codegen.
In HolyJit: A New HopeIt does link to https://github.com/nbp/holyjit which explains pretty much everything there is to explain so far...
In HolyJit: A New HopeBecause the first example that uses holyjit is an implementation [1] of the brainfuck [0] language.
[0]: https://en.wikipedia.org/wiki/Brainfuck
[1]: https://github.com/nbp/holyjit/blob/master/examples/brainfuc...
In HolyJit: A New HopeBecause it has an example that JITs Brainfuck: https://github.com/nbp/holyjit/blob/master/examples/brainfuc...
(They actually don’t even need that line, as Cargo already infers this via convention)
In HolyJit: A New Hopehttps://en.wikipedia.org/wiki/Brainfuck
The HolyJit repo has a brainfuck jit example in the repository: https://github.com/nbp/holyjit/blob/master/examples/brainfuc...
In HolyJit: A New HopeWhy does the Cargo.toml[1] file in the source repo for HolyJit have the word "brainfuck"[2] in it?
Does that have some significance to Rust or Mozilla? Or is this a case of copy pasta?
[1]: https://github.com/nbp/holyjit/blob/master/Cargo.toml
[2]: Permanent link to line: https://github.com/nbp/holyjit/blob/1f20eb41de2dae14179815c7...
In HolyJit: A New Hope