Hegel, a universal property-based testing protocol and family of PBT libraries
hegel.devA bit of an intro/announcement blog post for Hegel ("Hypothesis, Antithesis, synthesis", [0]) was submitted here ~2 weeks ago [1] and got a fair bit of discussion (106 comments).
I didn't expect to see Hegel when opening up HN today! Feel free to ask any questions about it. We released hegel-go earlier this week, and plan to release hegel-cpp sometime next week, so look forward to that :)
How exciting! I wrote my own pbt lib for zig (https://github.com/AntoineBalaine/zlowcheck) and it made me sad I couldn't get it nearly close to hypothesis. Looking forward to see this grow! Any hope for ffi through the c abi?
We plan to rewrite hypothesis in rust and expose an FFI through that! This is a medium term plan (months, not weeks or years), but we're acutely aware that relying on a python component is not a long-term solution.
Is the protocol documented so that other people can build language front-ends?
Yes! I just wrote up documentation for the protocol earlier this week: https://hegel.dev/reference/protocol.
In reality, we hope to provide more guidance than this to people who want to write their own language frontend. This protocol reference doesn't talk about the realities of [hegel-core](https://github.com/hegeldev/hegel-core) and how to invoke it, for example.
We intend to write a "How to write your own Hegel library" how-to guide. You can subscribe to this issue to get notified when we write that: https://github.com/hegeldev/website/issues/3.
If you're eager, pointing your favorite LLM at https://hegel.dev/reference/protocol + https://github.com/hegeldev/hegel-rust and asking it to write you one for your language of choice should be enough to get you started!
PSA: On the surface it looks great - but it's something that spawns a Python server (with uv - I think) and does communicate with it during tests. I don't think it's complexity we need to take on on our unit tests.
A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.
> A saner approach would be to start with a FFI-friendly language and create bindings. I don't think just being able to use an already written framework in Python is worth the trade-off.
For what it's worth the devs say their "current long-term plan is to implement a second Hegel server in Rust" [0], so the current state of affairs is probably a compromise between getting something usable for end users out and something more "sane", as you put it.
[0]: https://antithesis.com/blog/2026/hegel/#what%E2%80%99s-next
Oh god, as someone who studies and admires Hegel, please change the name from Hegel.
Completely agree. It's absolutely awful having software projects squatting on the names of great philosophers and artists. I appreciate that perhaps the author wanted to show their appreciation, but there are plenty of other equally communicative options.
Yo what has been the coolest thing about Hegel's philosophy you learned?
(I can really only do your question a modicum of justice by answering metaphorically.) That Anglo-American analytic philosophy, which has dominated much of 20th century Western philosophy and Western thought, was doomed from the start. It treated ontological Being as fixed, as beings nailed to a wall, lifeless and immobile. Hegelian philosophy, more than anything, is about movement.
Also I thought that 20th century analytic thought dissolved metaphysics entirely and didn't want to talk about it. I mean sure then you can question, "why delete metaphysics" but then you can't say that the 20th century brought this kind of stuff
> It treated ontological Being as fixed, as beings nailed to a wall, lifeless and immobile.
This reads more as a response to Plato & Kant
"didn't want to talk about it", absolutely. "dissolved metaphysics entirely", absolutely not.
Look, I read Continental philosophers too and I think they're cool, my point is that that kind of statement isn't what an analytic philosopher would say
Wait I thought Heidegger claimed that title? Or is he the guy who shifted Being from a noun to a verb, and Hegel's still focusing on the noun (just that the noun itself is a moving concept)?
Why? It’s perfectly coherent with the group of libraries and what they do.
It isn't. See: https://www.jstor.org/stable/2708045
I’ve read primary text excerpts from Hegel and some secondary sources too, and already knew that he didn’t write in that style, but the general idea that many forces in life develop themselves dialectically (the antithesis sometimes being expressed as alienation) is very similar in concept.
That a myth has developed around the terminology and methodology is persuading, but also there’s nothing wrong with a programming library to call itself Hegel.
Interesting paper regardless thanks for sharing.
On the other hand, I have quite the visceral reaction to the name because of the influence Hegel had on Marx, and subsequent 20th century critical theorists.
120% agree. it is so, so tasteless
A Hegel just flew over your house.
does anyone actually say it like that
How does this compare to https://academy.fpblock.com/blog/quickcheck-hedgehog-validit... ? As far as I understand, Validity also has free generators and shrinking for types by having them implement various typeclasses that represent invariants and also has pre-made combinators to test properties with.
So with the caveat that I'm not super familiar with Validity...
The biggest thing that leaps out at me looking at it is that Hegel is very built around flexible user-specified data generation (using the library's base generators and combinators) mixed freely with test execution. Validity in contrast looks extremely type-based, which is convenient when you're only testing fairly general properties of built-in types, but I've never found flexible enough to be a really good basis for property-based testing once your testing needs get even a bit more complicated. e.g. a lot of tests want some sort of upper and lower bounds on their numbers, and I don't want to define a type for each.
For an only slightly more involved example of this, suppose you've got, say, a Project type, and Projects have an owner that is a User. You might want a test that is about a single user that has some number of projects. In a generator-based approach, this is easy: You just generate a User object, then you generate a bunch of Project objects that have to have that User as their owner. Just works.
In contrast, in a type based approach, there's basically no way to express this without e.g. defining a new ProjectsOwnedByASingleUser type and defining what it means to be a valid instance of that type... It's a lot of machinery for what is IMO a strictly worse user experience.
Hypothesis: customer says something is bugged
Antithesis: the tests pass with 100% coverage
Synthesis: the bug is a feature
This is the first time I hear of property-based testing, and I am intrigued. What is the difference between this and a sufficiently expressive structural type system?
Given some system under test (SUT) with inputs (T, G...) and expected outputs derived from the inputs T', G' etc., a property based testing framework attempts to exercise the entire domain of values assignable to T, G, etc. against the SUT.
The generators of T, typically called an Arbitrary<T> can be constrained, e.g Arbitrary<number> could generate any float or just non-negative integers. Ideally we would define an Arbitrary<float64> or Arbitrary<u64>.
A sufficiently expressive type system makes it easier to narrow the gap between what is generated and what is assignable to type T, making it clearer what the valid input domain to the SUT is.
Great project!
This together with bombadil (web version pbt / Hegel / antithesis) for qa is a great advance.
We need more and more solutions like these for Agentic Coding.
Awesome! I've been waiting for hegel-go and can't wait to take it for a spin
I’m studying currently Phenomenology of Geist. No code is so gard to read as it.
Blah I need to get around to this!
I often gesture towards this phenomenology when religious folk casually attempt to claim "spirit" as some form of belief they hold over me. I honestly don't know if I've developed the position well, it is almost entirely through the lens of continental philosophy absorbing Hegel, but I use it to illustrate that my concept of spirit, as an atheist, may not be a different phenomenological occurrence than that of a religious framing and even shares the quality of a rich historical lineage I can draw from. I could just as easily retreat into untranslated German that sounds poetic or prophetic to the uninitiated, but that would be doing exactly what I'm asking them not to do, leaning on a vocabulary the other person can't engage with without first conceding the ground it's built on. This seems to effectively persuade them to adjust their vocabulary to a register I can actually engage with without needing to hedge for the axiomatic differences we have.
This is a comfortable mode of engagement and it is one I can share with religious folk, but I do find they often refuse this register and I will admit I can't always articulate why I find their refusal frustrating either.
Did you start with the Preface, or are you going to read it at the end?
(I strongly recommend the latter.)
I started the preface, read maybe a page and thought it was a joke and I actually downloaded somebody’s machine-generated lark. After brief study I jumped forward and also got some explanatory texts (Routledge guide) to read with it.
Just wait until you get into the Science of Logic
I'm starting with the Science of Logic!
I want to cry...
The first part of his Encyclopedia will help a lot, and might be better to read first before diving into SoL.
Off-topic but only today I was thinking of Hegel-related names for a certain business idea. Was wondering who had registered all the domains, well here's one. It would a completely different domain, and also a derivation of the name, so nothing to worry about there. But if I build something in Rust, I'll remember you :)
In the era of AI codegen, I think property-based testing will and should see greater uptake. Unit tests are too brittle for the grind on it till it works methods of agentic written code.
Now that's how you write a title.