JOjonny_eh·Jul 30, 2025
Apparently this is possible with macros? I dunno: https://github.com/leanprover/lean3/issues/1355
In The Math Is Hauntedleanprover
lean3
C++2014–2025
leanprover / lean3 · Archived
lean3
Lean Theorem Prover
13Distinct people
16Mentions
0Explicit recommenders
2.2KGitHub stars
What to know before exploring
What it is
Lean Theorem Prover
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
- leanprover/lean4 · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 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 year16 dated mentions
Observed mentions: 2014-06-21 13:07:37 UTC to 2025-07-30 21:54:52 UTC.
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 |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 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 | 1 | 0 | 1 |
What Hacker News says
16 sourcesSort of the official policy is that inside proofs (i.e., terms of types in Prop) constructibility doesn't matter, but inside definitions (i.e., terms of types in Type 0 and above) try to be constructive. For example, it is ok to define a function constructively but with a nonconstructive proof of termination.
LEM is used everywhere because it's actually a theorem. It follows from functional extentionality and the existence of quotient types. https://github.com/leanprover/lean/blob/master/library/init/...
The axiom of choice is an actual axiom, and it too ends up being used everywhere, but mostly to introduce decidable instances to permit things like double negation elimination inside proofs. An illustration: [1] introduces these instances to the file and [2] implicitly uses the instance.
[1] https://github.com/leanprover-community/math
Read the rest
Plus, it's a theorem in Lean: https://github.com/leanprover/lean/blob/master/library/init/...
(Lean has a somewhat different type theory from Coq, where propositions in Prop have the property that all proofs of a property are defined to be equal. It turns out this along with functional extensionality (that two functions are equal iff their evaluations are all equal) is enough to get LEM, but only in Prop. Outside Prop there's a stronger commitment to constructibility. Still, every definition and lemma has some program backing it.)
In Hindley-Milner Type Inference (2012)I'm not sure what you're talking about, unless you're saying truth is provability. (Classical logic would disagree.)
The Lean proof assistant, which has a pretty strong commitment to constructability, has the law of the excluded middle just fine: https://github.com/leanprover/lean/blob/master/library/init/...
The caveat is that it only exists in Prop, and it's a consequence of proof irrelevance and functional extensionality. Types outside Prop don't have it for the simple reason that there's no sensible way to construct an element of Either A (A -> Void) in general (this is quasi-Haskell notation, where Void is a type with no terms). I'm not sure there's any need to bring Godel into this....
In Hindley-Milner Type Inference (2012)For people interested in using Lean, note that there's a community fork (https://github.com/leanprover-community/lean) of the last official Lean 3 release 3.4.2 (https://github.com/leanprover/lean). The fork is still under active maintenance, so might be a better place to start (the main development team have moved onto developing Lean 4.0 (https://github.com/leanprover/lean4), and it's not clear when that will be ready).
In Doing a math assignment with the Lean theorem proverLean. It's implemented in a
dependently typed programming
Lean is implemented in C++ [1, 2]. There's a message in there somewhere. The message is probably something along the lines of: if you want performance, use a low-level language.
[1] https://github.com/leanprover/lean/tree/master/src
[2] https://github.com/leanprover/lean4/tree/master/src
In Haskell Problems for a New DecadeA few links (the chat is mentionned multiple times during the chat)
Lean: https://leanprover.github.io/
Repo: https://github.com/leanprover/lean/
Chat: https://leanprover.zulipchat.com/
The maths course (in French) that can be seen during the presentation: https://www.math.u-psud.fr/~pmassot/enseignement/math114/
License: Apache 2.0
I was afraid there would be a CLA, as is customary with Microsoft's projects (and the main reason I didn't contribute to any), but I couldn't find one. Good call.
> Lean 4
> We are currently developing Lean 4 in a new (private) repository. The source code will be moved here when Lean 4 is ready. Users should not expect Lean 4 will be backward compatible with Lean 3. [Committed one year ago]
Really, really not a fan of this. This basically prevents anyone from attempting to add new features or fixes, as they mi
Read the rest
ght be obsolete by the time the new version comes out (incompatible or already fixed).
Maybe just to elaborate: In contrast to rust, C++ is a standard defined language, with >3 mature and competitive implementations, two of which (clang / microsofts compiler) provide excellent tooling and support for refactoring (clang in particular) beyond any other language in existence (maybe except Java). Instead of looking at cppreference.com, maybe consider browsing https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... the Cpp Core Guidelines, this outlines a forward looking vision of how good c++ code should look like.
A lot of the static guarantees that rust provides can be modelled in C++ as well, see for example "https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel.... Eventually someone will write a rust-style borrow checker as a clang analysis pass. Already now it is possible to express a lot of
compile time pr
Read the rest
operties cleanly in c++, with features such as constexpr lambdas, static_assert etc. Additional features such as Concepts / meta-classes / modules will improve C++ expressivity even further.
In short, yes C++ has a lot of stuff and everyone knows that it is hard to get a grip on all its features and misfeatures. But there has been a continuous effort to rectify and improve on its short comings. See for example https://clang.llvm.org/extra/clang-tidy/checks/list.html for a list of clang based code transformations that are able to automatically improve your c++ code.
The way I see it, just because of legacy reasons (I can interface with the majority of commercial software developed in the last 30 years (CAD, EDA software, Houdini, Abelton, ...)), tooling reasons (the rust compiler is a slow hot mess, compared to the state of the art c++ compilers) and momentum (there is a large incentive to continuously improve c++, because it is the foundation of a large fraction of commercial software out there) it is unlikely that rust will outcompete c++ in a significant way in the long run.
To close of with an example the lean theorem prover https://github.com/leanprover/lean, implemented in C++ handily beats the 20+ year old Coq prover. One of its key features is multicore support. If you look into its implementation details, the equivalent rust code would have to work around a lot of rust "safety" features, essentially because in many cases it is hard to convince a hardcoded heuristic like a borrow checker that whatever you are doing is safe. The static guarantees that rust gives wouldn't help you at all in correctly implementing some of the very involved algorithms a theorem prover kernel has to implement, while standing in the way of the implementation being straightforward. This leaves aside the obvious tooling (you can use Visual Studio, good profilers and debuggers) and integration (SAT checkers like Z3, LLVM backend) advantages.
As far as C++ code goes, the Lean Prover is really well maintained: https://github.com/leanprover/lean
I'd also say GHC is quite good.
And Pandoc as well.
I don't think I can compute enough variables to consider the "highest" though... so the aforementioned are only examples of what I think are good.
In Ask HN: What open source project, in your opinion, has the highest code quality?Interesting note: a new version, Lean 4, is currently under development, which will presumably replace Lean 3 once complete: https://github.com/leanprover/lean/blob/master/doc/lean4.md.
In Theorem Proving in LeanNo, it's not true, it "extracts" (compiles) to C++. <https://github.com/leanprover/lean/pull/1241> It's written in Lean itself, as a metaprogram. The code it generates calls into the Lean library ("runtime") for some objects, otherwise uses native types when it can. vm_obj's in Lean are reference counted. There's also in-progress work on an LLVM backend.
In Coq-based synthesis of Scala programs which are correct-by-construction [pdf]If you're interested in this kind of thing, note that Coq can also extract code in Haskell, Scheme and OCaml.
If Coq's not quite your cup of tea, Isabelle/HOL is another proof assistant with amazing (dare I say superior?) tooling and automation, and it supports code extraction in SML, OCaml, Haskell and Scala.
Microsoft Research's Lean theorem prover is also promising in this regard. Work is almost complete on native code compilation (via C code extraction), allowing you to compile all the constructions you can formalize in Lean directly to native code. (see https://github.com/leanprover/lean/pull/1241 for progress)
(Note that none of those code extractors are verified to be correct themselves, lacking a formalization of the target language's semantics. You don't get a mathematical proof that the code you're running does what you specifie
Read the rest
d, but you get pretty damn close.)
I don't think so. I'm not really competent to say if the NLP part will be solved soon, but (fully) automated theorem proving is very hard, and I don't see deep learning applying to it very well.
What could happen, though (hopefully), is that mathematicians start using more and more the various proof assistants (Coq, Isabelle/HOL, lean, …). These allow to write definitions, statements, theorems in a more programming-like way, with structured proofs; to develop modular libraries; and even in some cases to use automated provers to wave away details of the proofs. The problem of adoption of such provers, however, is a culture problem, not really a technology problem: as said elsewhere, mathematicians do not seem to care too much about formal correctness. It's only if automated tools help gaining insights (automatic search for (counter)example
Read the rest
s, for example; function plotting; builtin algebra solving system… ?) that they will convince more people to use them. Modularity might also be a selling point, but not sufficient to overcome the steep learning curve of these tools.
I have some hopes in [lean](https://github.com/leanprover/lean), a new proof assistant inspired from Coq, which puts the focus on good UI and automation.
There is a PR for a Lean backend producing both C++ and Rust: https://github.com/leanprover/lean/pull/1090 Note, however, that this is purely focused on executing Lean code, not integrating with other C++/Rust sources.
In A Formal Verification of Rust's Binary Search ImplementationShowing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.