I recently shared another similar mathstodon post https://mathstodon.xyz/@tao/111287749336059662

This link, however, is related to a different paper.

I'm kind of interested in how useful Lean4 is as a programming language, and if it's easy to prove things about a program written in Lean. I should probably look into that when I have a minute.

Regarding usefulness: Lean is very nice to program in, if you care about pure functional languages; its FFI allows you to incorporate fast C routines very easily if pure Lean is not performant enough or lacks features. However, in some domains, Lean is within a decimal order of magnitude of (not hand-optimized) C; some benchmarks I hand-made recently impressed me.

Regarding proving things about programs, no, it is not easy, and the developers do not seem to consider it a core goal of Lean.

> the developers do not seem to consider it a core goal of Lean

I guess it depends on who you ask. The original devs of Lean wanted to do "everything" (because that's how you start projects, I guess). Since then it has attracted a lot of mathematicians (especially those working on Mathlib, a library that aspires to formalize "all known math") who are happy to have "algorithm objects" and prove things about them without being able to actually run an algorithm on any input.

This goes together with mostly embracing classical logic (which breaks the original and most powerful version of Curry-Howard, which allowed you to extract programs from proofs). However, in practical situations, algorithms extracted in this way tend to be too slow to be useful, so maybe that's not actually a downside for programming purposes.

Finally, Lean4 "compiles" to C-code, so at least it is (or can reasonably easily be made) portable. People have been trying to use it for real applications, like the AWS stuff others have linked in this thread.

The core Lean 4 developers do want proving properties about programs to be easy. In the short term maybe priorities have been elsewhere due to limited resources, but that doesn't mean they do not consider this to be a core goal. My understanding is that there are still some research-level problems here that need to be worked out. (Proving things about do notation is currently a real pain for example.)

This turned out to be a pretty cool project: It forced me to carefully handle the async nature of react's setState.

I also implemented some cheating protection etc. which was a pretty cool extra challenge.

This is great! Out of curiosity, it seems like you've presented this anonymously on purpose (no credits on site, username is gridentio, etc), just wondering why that is?

Thanks! I've been discussing whether I should present this as a personal project or credit our small startup. :)

I'll add some creds soon.