{"slug": "rocq", "name": "Rocq", "category": "other", "category_name": "Other software", "description": "", "recommenders": 5, "commenters": 23, "warners": 1, "score": 7.34, "rising": -0.31, "first": "2025-11-02", "latest": "2026-10-31", "why": "look into Rocq (which uses CoIC, like Lean, but is more rigorous about it)", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 16, "compare": 2, "warn": 1}, "spark": [2, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1], "listed": true, "loved": [], "caveat": "", "short_quote": "look into Rocq (which uses CoIC, like Lean, but is more rigorous about it)", "kind": "", "icon": true, "domain": "rocq-prover.org", "github_repo": null, "official_url": "https://rocq-prover.org", "pricing": "", "aliases": ["Rocq"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 799068113, "item_id": 49941757, "url": "https://news.ycombinator.com/item?id=49941757", "by": "BalinKing", "date": "2026-10-03", "stance": "recommend", "quote": "which doubles as an introduction to Rocq", "excerpt": "IMO the experience of learning to use and understand a proof assistant gives one a pretty good foundation for then going deeper into logic and proof theory. I'm specifically thinking of Logical Foundations [0], which doubles as an introduction to Rocq and also an introduction to intuitionistic logic (and also type theory!). Some specific disagreements: - \"Proof trees\" on Wikipedia redirects to the page for analytic t", "context": "", "use_case": "Proof assistant", "switched_from": "", "story": "Anatomy of a Lean proof for software engineers"}, {"id": 779883296, "item_id": 48742706, "url": "https://news.ycombinator.com/item?id=48742706", "by": "tsterin", "date": "2026-06-30", "stance": "recommend", "quote": "use https://rocq-prover.org/ for that purpose", "excerpt": "use https://rocq-prover.org/ for that purpose", "context": "", "use_case": "", "switched_from": "", "story": "Leanstral 1.5"}, {"id": 750815553, "item_id": 46925972, "url": "https://news.ycombinator.com/item?id=46925972", "by": "wizzwizz4", "date": "2026-02-07", "stance": "recommend", "quote": "look into Rocq (which uses CoIC, like Lean, but is more rigorous about it)", "excerpt": "Lean 4 is not a theoretically-interesting proof assistant. If you're interested in such things, look into Rocq (which uses CoIC, like Lean, but is more rigorous about it), the HOL logic, Isabelle/HOL's automation suite (though Isabelle proper is fairly mediocre, apart from being the thing everyone's standardised around), Lean-auto (https://arxiv.org/abs/2505.14929), and whatever SAT solvers are state-of-the-art this ", "context": "", "use_case": "", "switched_from": "", "story": "First Proof"}, {"id": 733611650, "item_id": 45850728, "url": "https://news.ycombinator.com/item?id=45850728", "by": "specialgoodness", "date": "2025-11-07", "stance": "recommend", "quote": "Don't forget the amazing theorem provers too", "excerpt": "Xavier Leroy as Lou Reed... :-) Don't forget the amazing theorem provers too, like Imandra ( https://www.imandra.ai/core ), HOL-Light ( https://hol-light.github.io/ ) and Rocq ( https://rocq-prover.org/ ), ... !", "context": "", "use_case": "", "switched_from": "", "story": "Why I love OCaml (2023)"}, {"id": 732730930, "item_id": 45795683, "url": "https://news.ycombinator.com/item?id=45795683", "by": "nextos", "date": "2025-11-02", "stance": "recommend", "quote": "Rocq (dependently typed), which also has a great track record.", "excerpt": "> there is not anything necessarily wrong with dependent types, but that he doesn't believe they are necessary. I think that, at least in software engineering, his point has not been disproven. Isabelle (classical) has a great track record in software verification. I don't see it as something inherently inferior to Rocq (dependently typed), which also has a great track record. Lean doesn't have a great focus (yet?) o", "context": "", "use_case": "", "switched_from": "", "story": "Why don't you use dependent types?"}]}], "caveats": [], "who": [{"by": "wbeckler", "context": "works on the Open Markets Initiative", "url": "https://news.ycombinator.com/item?id=50316022", "date": "2026-10-31"}, {"by": "dwohnitmok", "context": "has done work in formal verification", "url": "https://news.ycombinator.com/item?id=49756577", "date": "2026-09-18"}], "tags": [], "use_cases": ["formal verification", "theorem proving", "proof assistant", "software verification"], "compared": [{"slug": "lean", "name": "Lean", "co": 10, "switched_from": 0, "switched_to": 0}, {"slug": "crane", "name": "Crane", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "dafny", "name": "Dafny", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "isabelle", "name": "Isabelle", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "tlaplus", "name": "TLA+", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "hol-light", "name": "HOL Light", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46689631", "title": "Extracting verified C++ from the Rocq theorem prover at Bloomberg", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=50202217", "title": "LLMs are making formal software verification feasible at a much larger scale", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49323459", "title": "The Case Against Formal Verification, 50 Years Later", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50290652", "title": "AI, Lean, and the Future of Formal Verification, with Lean Creator Leo de Moura", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50024090", "title": "What mathematicians should know about the Lean Theorem Prover: reliability & AI", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49925602", "title": "Anatomy of a Lean proof for software engineers", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 2}, "2025-12": {}, "2026-01": {"neutral": 5}, "2026-02": {"recommend": 1, "compare": 1}, "2026-03": {}, "2026-04": {"neutral": 1}, "2026-05": {}, "2026-06": {"recommend": 1}, "2026-07": {"compare": 1, "neutral": 1}, "2026-08": {"neutral": 5}, "2026-09": {"neutral": 1}, "2026-10": {"recommend": 1, "warn": 1, "neutral": 3}}, "quotes": [{"id": 805056354, "item_id": 50316022, "url": "https://news.ycombinator.com/item?id=50316022", "by": "wbeckler", "date": "2026-10-31", "stance": "neutral", "quote": "we've generated millions of lines of Lean 4, TLA+, and Rocq", "excerpt": "I think the royal combo is Lean 4/TLA+/etc. plus AI plus a deterministic generator. For large systems formal method assertions need to be compressed down to a human comprehensible size. This can happen when the assertions are confirming the accuracy of a model and its attached code generators. The generator can generate proofs of the generated code and a human only needs to ensure that the generator provably generate", "context": "works on the Open Markets Initiative", "use_case": "formal verification", "switched_from": "", "story": "AI, Lean, and the Future of Formal Verification, with Lean Creator Leo de Moura"}, {"id": 803423633, "item_id": 50213977, "url": "https://news.ycombinator.com/item?id=50213977", "by": "mbac32768", "date": "2026-10-23", "stance": "neutral", "quote": "Rocq does not have trusting trust concerns since it's implemented in OCaml and C", "excerpt": "Re: footnote 5 > This technically also means we have to trust the hardware, OS, OCaml compiler that the Rocq proof checker relies on. It just so happens Claude and I recently did an independent implementation of OCaml and ruled out malware in the compiler bootstrap via DDC (and also by achieving byte identical outputs). https://discuss.ocaml.org/t/ocaml-compiler-implemented-in-c-its-not-just-faster-it-also-increases-", "context": "", "use_case": "", "switched_from": "", "story": "LLMs are making formal software verification feasible at a much larger scale"}, {"id": 803284832, "item_id": 50205302, "url": "https://news.ycombinator.com/item?id=50205302", "by": "jasongross", "date": "2026-10-23", "stance": "neutral", "quote": "imported into Rocq with rocq-read-file", "excerpt": "Model: https://github.com/theorem-labs/rocq-linux-process-semantics based on https://github.com/mit-plv/riscv-coq and Sail Binaries are split into sections with a Python script and imported into Rocq with rocq-read-file Workflow: https://theorem.dev/oss-verify/ , https://github.com/theorem-labs/oss-verify , https://github.com/theorem-labs/oss-verify-proofs", "context": "", "use_case": "", "switched_from": "", "story": "LLMs are making formal software verification feasible at a much larger scale"}, {"id": 800523440, "item_id": 50032715, "url": "https://news.ycombinator.com/item?id=50032715", "by": "123a7a", "date": "2026-10-10", "stance": "warn", "quote": "", "excerpt": "Indeed. The people who suggested the change in 2021 and the mailing list threads have been purged from the search engines, but this thread is still here: https://news.ycombinator.com/item?id=26738980 Talia Ringer, the main proponent, now writes posts that AI will turn out OK (and works on proof automation for programs so that more software engineers can become unemployed): https://terrytao.wordpress.com/2026/09/17/be", "context": "", "use_case": "", "switched_from": "", "story": "What mathematicians should know about the Lean Theorem Prover: reliability & AI"}, {"id": 799068113, "item_id": 49941757, "url": "https://news.ycombinator.com/item?id=49941757", "by": "BalinKing", "date": "2026-10-03", "stance": "recommend", "quote": "which doubles as an introduction to Rocq", "excerpt": "IMO the experience of learning to use and understand a proof assistant gives one a pretty good foundation for then going deeper into logic and proof theory. I'm specifically thinking of Logical Foundations [0], which doubles as an introduction to Rocq and also an introduction to intuitionistic logic (and also type theory!). Some specific disagreements: - \"Proof trees\" on Wikipedia redirects to the page for analytic t", "context": "", "use_case": "Proof assistant", "switched_from": "", "story": "Anatomy of a Lean proof for software engineers"}, {"id": 796105232, "item_id": 49756577, "url": "https://news.ycombinator.com/item?id=49756577", "by": "dwohnitmok", "date": "2026-09-18", "stance": "neutral", "quote": "my main toolbox of formal verification tools in the past have been Rocq, Idris, Dafny, and TLA+", "excerpt": "I would encourage you to think more deeply about the assertions you're making here. I've done a fair amount of work in this space as well, specifically my main toolbox of formal verification tools in the past have been Rocq, Idris, Dafny, and TLA+, and I can say that I've come away with roughly the same set of tradeoffs as what LightMachine describes in his comment. Current formal verification tools are often very sl", "context": "has done work in formal verification", "use_case": "formal verification", "switched_from": "", "story": "Bend 2 and the Vibe-Coding Trap"}, {"id": 789190352, "item_id": 49324397, "url": "https://news.ycombinator.com/item?id=49324397", "by": "Nail2680", "date": "2026-08-16", "stance": "neutral", "quote": "It seemed to me from the survey that most people didn't want it changed or didn't care", "excerpt": "Huh, I missed all of that. The linked discussion about the renaming from your link was a bit odd: https://discourse.rocq-prover.org/t/coq-community-survey-2022-results-part-iv-and-itp-paper-announcement/2001#renaming-coq-8 It seemed to me from the survey that most people didn't want it changed or didn't care, but due to anglophone users they decided to change it anyway.", "context": "", "use_case": "", "switched_from": "", "story": "The Case Against Formal Verification, 50 Years Later"}, {"id": 789188336, "item_id": 49324271, "url": "https://news.ycombinator.com/item?id=49324271", "by": "djsjajah", "date": "2026-08-16", "stance": "neutral", "quote": "I think it\u2019s rocq now.", "excerpt": "It\u2019s been renamed recently. Maybe a few times. I think it\u2019s rocq now. [1] [1] https://rocq-prover.org/docs", "context": "", "use_case": "Theorem proving", "switched_from": "", "story": "The Case Against Formal Verification, 50 Years Later"}, {"id": 789183905, "item_id": 49323994, "url": "https://news.ycombinator.com/item?id=49323994", "by": "dev_dan_2", "date": "2026-08-16", "stance": "neutral", "quote": "I would assume the variants used in Rocq and Lean are proven sound.", "excerpt": "Huh. Thanks for bringing that into my attention, and the link! Yes, in hindsight it makes sense that a eager LLM would exploit bugs in the kernel itself. I have not read the details yet (but want to!) and assume that it is rather related to the layers directly before or after the type-theory core; i.e. that the AI managed to get a correct typecheck by sidestepping a check during in one of the translation steps someho", "context": "", "use_case": "", "switched_from": "", "story": "A SAT Attack on Tarski's High School Algebra Problem"}, {"id": 788731856, "item_id": 49295741, "url": "https://news.ycombinator.com/item?id=49295741", "by": "antonvs", "date": "2026-08-14", "stance": "neutral", "quote": "the Coq (now Rocq) theorem prover", "excerpt": "You should take a look at \"The Calculus of Constructions\" (1988), which is one of the seminal papers that describes the basis for the Coq (now Rocq) theorem prover: https://www.academia.edu/47789825/The_calculus_of_constructions Here's a very relevant quote from the introduction: > \"The calculus of constructions is a higher-order formalism for constructive proofs in natural deduction style. Every proof is a lambda-ex", "context": "", "use_case": "theorem proving", "switched_from": "", "story": "Tim Gowers: What sort of maths are LLMs good at?"}, {"id": 786868514, "item_id": 49179282, "url": "https://news.ycombinator.com/item?id=49179282", "by": "momentoftop", "date": "2026-08-04", "stance": "neutral", "quote": "Provers such as Rocq (and I assume Lean) additionally want their proof objects", "excerpt": "Pretty much. The kernel of a proof assistant is the absolutely trusted core, and ultimately gets to decide what is or isn't a proven mathematical fact (so roughly a kernel resource). Over that, you build a huge amount of (userspace) tooling that doesn't have to be absolutely trusted since its job is just to talk into the kernel and get theorems. A kernel bug manifests as the kernel deciding that something is a theore", "context": "", "use_case": "", "switched_from": "", "story": "Why is it all in the kernel?"}, {"id": 785048992, "item_id": 49065562, "url": "https://news.ycombinator.com/item?id=49065562", "by": "cayley_graph", "date": "2026-07-26", "stance": "neutral", "quote": "I did spend a grad class with rocq (coq at the time)", "excerpt": "> I\u2019m not even going to get into how you could provably transform brute force propositional logic into efficient algorithms. > The entire problem is showing that an efficient/reliable program actually implements those rules. Reliability is a standard matter of correctness and captured (partly) by specifications. Efficiency tends to be easy to empirically test, but it is also possible to capture at the specification l", "context": "", "use_case": "", "switched_from": "", "story": "We have proof automation now"}, {"id": 783644752, "item_id": 48977797, "url": "https://news.ycombinator.com/item?id=48977797", "by": "baq", "date": "2026-07-20", "stance": "compare", "quote": "", "excerpt": "pay attention to this one https://higherorderco.com/ and wait for bend2 announcements", "context": "", "use_case": "", "switched_from": "", "story": "Claude Fable produced a counterexample to the Jacobian Conjecture"}, {"id": 779883296, "item_id": 48742706, "url": "https://news.ycombinator.com/item?id=48742706", "by": "tsterin", "date": "2026-06-30", "stance": "recommend", "quote": "use https://rocq-prover.org/ for that purpose", "excerpt": "use https://rocq-prover.org/ for that purpose", "context": "", "use_case": "", "switched_from": "", "story": "Leanstral 1.5"}, {"id": 764997584, "item_id": 47812349, "url": "https://news.ycombinator.com/item?id=47812349", "by": "andreweggleston", "date": "2026-04-17", "stance": "neutral", "quote": "", "excerpt": "And now instead of being confused for a bad word, it gets confused with https://www.roc-lang.org/", "context": "", "use_case": "", "switched_from": "", "story": "Coq theorem prover is now called Rocq"}, {"id": 753105363, "item_id": 47069085, "url": "https://news.ycombinator.com/item?id=47069085", "by": "nextos", "date": "2026-02-18", "stance": "compare", "quote": "Why3, Rocq and Agda are other obvious contenders.", "excerpt": "If verification is the goal, but you don't want to learn theorem proving yet, Dafny is really approachable and practical [1]. F* is also worth considering as a proof-oriented alternative to Isabelle that is focused on software verification [2]. Why3, Rocq and Agda are other obvious contenders. [1] https://dafny.org/latest/OnlineTutorial/guide [2] https://fstar-lang.org/tutorial", "context": "", "use_case": "software verification", "switched_from": "", "story": "Learning Lean: Part 1"}, {"id": 750815553, "item_id": 46925972, "url": "https://news.ycombinator.com/item?id=46925972", "by": "wizzwizz4", "date": "2026-02-07", "stance": "recommend", "quote": "look into Rocq (which uses CoIC, like Lean, but is more rigorous about it)", "excerpt": "Lean 4 is not a theoretically-interesting proof assistant. If you're interested in such things, look into Rocq (which uses CoIC, like Lean, but is more rigorous about it), the HOL logic, Isabelle/HOL's automation suite (though Isabelle proper is fairly mediocre, apart from being the thing everyone's standardised around), Lean-auto (https://arxiv.org/abs/2505.14929), and whatever SAT solvers are state-of-the-art this ", "context": "", "use_case": "", "switched_from": "", "story": "First Proof"}, {"id": 748277890, "item_id": 46767368, "url": "https://news.ycombinator.com/item?id=46767368", "by": "mzweav", "date": "2026-01-26", "stance": "neutral", "quote": "reason directly over the functional code in Rocq", "excerpt": "I'm the other dev of Crane. Our current plan is to use BRiCk (https://skylabsai.github.io/BRiCk/index.html) to directly verify that the C++ implementation our STM primitives are extracted to matches the functional specification of STM. Having done that, we can then axiomatize the functional specification over our monadic, interaction tree interface and reason directly over the functional code in Rocq without needing ", "context": "", "use_case": "", "switched_from": "", "story": "Extracting verified C++ from the Rocq theorem prover at Bloomberg"}, {"id": 747929201, "item_id": 46745575, "url": "https://news.ycombinator.com/item?id=46745575", "by": "aleksejs", "date": "2026-01-24", "stance": "neutral", "quote": "only the source (Rocq) programs that are formally verified", "excerpt": "The linked website and repository do not refer to the outputs as \"verified C++\". The use of that term in the submission title here seems misleading, and the Design Principles [1] document clarifies it is only the source (Rocq) programs that are formally verified. It seems far from obvious that the complex and ad-hoc syntactic transformations involved in translating them to C++ preserve the validity of the source proo", "context": "", "use_case": "", "switched_from": "", "story": "Extracting verified C++ from the Rocq theorem prover at Bloomberg"}, {"id": 747925552, "item_id": 46745347, "url": "https://news.ycombinator.com/item?id=46745347", "by": "zero-sharp", "date": "2026-01-24", "stance": "neutral", "quote": "", "excerpt": "If I understand this correctly, it translates Rocq to C++? Took me several minutes to even understand what this is. Why is it called an extraction system? Who is this for? I'm confused. edit: I had to dig into the author's publication list: https://joomy.korkutblech.com/papers/crane-rocqpl26.pdf Testing remains a fundamental practice for building confidence in software, but it can only establish correctness over a fi", "context": "", "use_case": "", "switched_from": "", "story": "Extracting verified C++ from the Rocq theorem prover at Bloomberg"}, {"id": 747882881, "item_id": 46742680, "url": "https://news.ycombinator.com/item?id=46742680", "by": "joomy", "date": "2026-01-24", "stance": "neutral", "quote": "You can map Rocq `bool`s to C++ `bool`", "excerpt": "Hi, I'm one of Crane's developers. You can map Rocq `bool`s to C++ `bool`, Rocq strings to C++ `std::string`s, etc. You just have to manually import the mapping module: https://github.com/bloomberg/crane/blob/6a256694460c0f895c279323792b14f4c2076909/theories/Mapping/Std.v The output you posted is from an example that we missed importing. It's also one of the tests that do not yet pass. But then again, in the readme, ", "context": "", "use_case": "", "switched_from": "", "story": "Extracting verified C++ from the Rocq theorem prover at Bloomberg"}, {"id": 746511504, "item_id": 46656969, "url": "https://news.ycombinator.com/item?id=46656969", "by": "crvdgc", "date": "2026-01-17", "stance": "neutral", "quote": "program extraction like in Rocq probably deserves some discussion", "excerpt": "Some valid points, but I hope the authors had developed them more. On the semantic gap between the original software and its representation in the ITP, program extraction like in Rocq probably deserves some discussion, where the software is written natively in the ITP and you have to prove the extraction itself sound. For example, Meta Rocq did this for Rocq. For the how far down the stack problem, there are some eff", "context": "", "use_case": "", "switched_from": "", "story": "Lies, Damned Lies and Proofs: Formal Methods Are Not Slopless"}, {"id": 733611650, "item_id": 45850728, "url": "https://news.ycombinator.com/item?id=45850728", "by": "specialgoodness", "date": "2025-11-07", "stance": "recommend", "quote": "Don't forget the amazing theorem provers too", "excerpt": "Xavier Leroy as Lou Reed... :-) Don't forget the amazing theorem provers too, like Imandra ( https://www.imandra.ai/core ), HOL-Light ( https://hol-light.github.io/ ) and Rocq ( https://rocq-prover.org/ ), ... !", "context": "", "use_case": "", "switched_from": "", "story": "Why I love OCaml (2023)"}, {"id": 732730930, "item_id": 45795683, "url": "https://news.ycombinator.com/item?id=45795683", "by": "nextos", "date": "2025-11-02", "stance": "recommend", "quote": "Rocq (dependently typed), which also has a great track record.", "excerpt": "> there is not anything necessarily wrong with dependent types, but that he doesn't believe they are necessary. I think that, at least in software engineering, his point has not been disproven. Isabelle (classical) has a great track record in software verification. I don't see it as something inherently inferior to Rocq (dependently typed), which also has a great track record. Lean doesn't have a great focus (yet?) o", "context": "", "use_case": "", "switched_from": "", "story": "Why don't you use dependent types?"}]}