RYryan-ca·Jul 2, 2026Submission
Hobbes – A Language and Embedded JIT Compiler
36 points · Open discussionmorganstanley
hobbes
C2017–2026
morganstanley / hobbes
hobbes
A language and an embedded JIT compiler
8Distinct people
33Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
A language and an embedded JIT compiler
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
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, 5:04:57 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 year33 dated mentions
Observed mentions: 2017-06-19 23:08:10 UTC to 2026-07-02 23:52:11 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 | 6 | 2 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 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 | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 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 | 2 | 2 | 0 |
What Hacker News says
33 sourcesI made something like this for Morgan Stanley some years ago, a structurally typed eager variant of Haskell with static elimination of type class constraints (so no runtime penalty for overloading) and uses LLVM for the back-end:
http://github.com/morgan-stanley/hobbes/
We used it for processing and analyzing billions of events per day. Using structural algebraic types let us encode market data (obviously) but also complex data structures inside trading systems that we could correlate with market data.
As you say, Haskell-ish expressions are much more compact and capable than SQL, which was one of the reasons I wanted to build it.
It also had a somewhat novel compression method (“types as probabilities” if you like the old Curry-Howard view), which was very important to manage billions of daily events.
Good times.
In Haskell Postgres Stored ProceduresThis piece focuses on complaints about ocaml, and the last half seems to just be syntax complaints (which I mostly ignore just because every language seems to have awkwardness in its syntax -- certainly Haskell, a language otherwise held up as an example, can be shown to accept some really weird text).
Good things about ocaml that I think should be mentioned are Hindley-Milner type inference (some might argue this, but it's a very effective system for inferring types), and also straightforward semantics (it's usually pretty easy to look at some code and make a reasonably accurate guess about what it will do on real hardware -- compare with Haskell).
I'm sympathetic toward the initial complaints here, which I also think are the most substantive. Type classes and qualified types, as in Haskell, would be very useful in ocaml/ML. The exampl
Read the rest
es offered (show_of_int, show_of_double, ...) are valid, and also the related complaint that dishonestly broad types like structural equality (where runtime errors are raised for cases where the types are actually not supported) also make a compelling case for qualified types in ML.
I made this project ~10 years ago after making similar observations:
https://github.com/morganstanley/hobbes
Things like structural equality and ordering are user functions here rather than magic internal definitions (e.g. equality is defined as a type class, and type class instances can deconstruct algebraic types at compile time to decide how to implement instances). But evaluation is eager by default, so it's pretty easy to reason about performance. And data structures can be persisted to files and/or shared transparently in memory with C/C++ programs without translation, also very convenient for the places where this was used. Actually we built some very big and complicated time series databases with it, used in both pre and post trade settings where ~15% of daily US equity trades happen. So I think these observations are useful and have passed through some pretty significant real tests.
Very cool, this approach will inevitably catch on, I think.
I built a similar typed PL and compiler for Morgan Stanley back in 2013:
https://github.com/morganstanley/hobbes
In APL and Array ProgrammingYou're right about term rewriting as a staged evaluation scheme. Similar to Haskell, I made this PL/compiler for Morgan Stanley where qualified type constraints (for e.g. type classes) are interpreted as stage-0 programs and rewritten into stage-1 programs that compile down to stage-2 programs (so a similar kind of stratification):
https://github.com/morganstanley/hobbes
It looks like this method is aimed at doing user pattern-matching on expressions in the first stage, kind of integrating Haskell-style rewrite rules in the main user language (rather than bolting them on the side in comments).
In Show HN: Peridot – A functional language based on two-level type theoryRe: no open source alternative to kdb
I built this for Morgan Stanley (the same place where kdb originally came from) and put it to use in some major high-volume/low-latency trading systems where a significant fraction of US equity trades execute every day:
https://github.com/Morgan-Stanley/hobbes/
In InfluxDB is betting on Rust and Apache Arrow for next-gen data storeShameless plug, I made hobbes and used it in high volume trading systems at Morgan Stanley:
https://github.com/Morgan-Stanley/hobbes
It’s kind of a structurally-typed variant of Haskell, integrates closely with C++, produces very fast code.
In Fast high-level programming languagesI think that part of the problem is to define data structures in a way that can be produced and consumed in multiple languages, algebraic data types are a good "least common denominator" for this.
Also w.r.t. reinventing the schema for databases, I have got a lot of mileage out of deriving the schema from code. Shameless plug, I have this little project (https://github.com/Morgan-Stanley/hobbes/) where we have a self-contained header-only library to push structured data out of process with minimal latency, query data concurrently with a Haskell-like PL. It works well for our kinds of systems (millions of orders per day, ~1 billion market data ticks, structured log data from multiple systems involved, ...).
In How to Evangelize a Programming LanguageAnother voice in favor of logging. At Morgan Stanley we wind up recording about 1TB/day of structured log data, which also needs an efficient query engine to process. We carved a basic type system out for structured data, maps to C++ data well, and built a Haskell-like PL (and JIT compiler built on LLVM) to process it:
https://github.com/Morgan-Stanley/hobbes/
The logging part is just a single self-contained header-only lib, so very easy to incorporate in existing systems.
In Do not logThere are many good points about KDB/Q the product (most of all simplicity) and it certainly was well-engineered. But K is not a modern language and its performance is only impressive as an interpreted language; and these gains come at a significant cost (various limits on expression sizes / variable counts / branch sizes, no closures, poor error messages). It's only really "fast" on bulk operations, much like Python.
If you want to see what a modern K or Q might look like (with static types and an embedded JIT compiler!), checkout the excellent Hobbes project from Morgan Stanley:
https://github.com/Morgan-Stanley/hobbes
In K Language (2011)I agree especially with the proposition that we should exchange structured data (via files, network connections, ...).
I started this project several years ago to support live code updates in production systems without sacrificing performance, but I eventually hit the same issues with exchanging structured data:
https://github.com/Morgan-Stanley/hobbes
I split out structured logging into a single header-only lib, structured RPC into a single header-only lib, etc. It's not quite the same as having native support in the OS, but because the mechanism is so lightweight (don't even need to link anything special), it's a pretty good substitute.
In Programmer's critique of missing structure of operating systems> Anyway, I think the way out of this mess is to have a functional, Haskell-like language for processing tables
I agree, and in a Haskell-like setting we can have any structured types (rather than just primitives).
That’s why I built hobbes:
https://github.com/Morgan-Stanley/hobbes
In Is a Dataframe Just a Table? (2019) [pdf]The language is quite interesting https://github.com/Morgan-Stanley/hobbes#evaluation: e. g. anonymous variants, isorecursive types.
In Hobbes – A Language and an Embedded JIT CompilerShowing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.