A 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.
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.
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.
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.
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.
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.
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.
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?
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 :)
41 comments
[0]: https://antithesis.com/blog/2026/hegel/
[1]: https://news.ycombinator.com/item?id=47504094
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!
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
Antithesis: the tests pass with 100% coverage
Synthesis: the bug is a feature
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.