I've been on this horse for a while now. I've settled on learning Ada/SPARK. Ada 2022 will start feeding a new SPARK 2014 update. Yes, they are both verbose, if you don't like that sort of thing, and don't like Pascal-like syntax. Believe me, I like APL/J/k/uiua/BQN and Forth and ASM. I am usually syntax agnostic as long as the PL and the ecosystem (more important than most think), meet your needs. I tried Rust back in 2018, and then again in 2023, but found it very complex and Ok, not a fan of the syntax. I would have preferred more ML or Haskell-like syntax. Zig seemed nice, but different use case, and too new. After all, Ada/SPARK have been on huge, high-assurance, high-safety applications for decades. Rust is getting some of their love, and vice versa. AdaCore had created a verified Rust compiler, but with a real world product (Blacktail hoist) in the works, we need a toolset and guarantees and ease of auditing and acceptance to achieve high safety and standards certifications. Think aerospace, defense, railway, and automotive. I started programming in 1977, so there's always a place in my heart for ASM/C. I played with F#, F*, and LOW from MS, and they are good, but they and Rust simply don't have the real world legacy of Ada/SPARK. I have been using Shen to write some formally verified models of less safety-critical areas of our software and I find it refreshing, however, my day job is to stay focused on Ada/SPARK until Rust matures more with a formally verifed proven toolset. There are certainly efforts and crates available in that direction, so hopefully others will bring it to where it needs to be. Lean is another one I have been playing with for some of the more overall logic proof of the system we are building.

I really think that verification aware languages are going to become a necessity

Wrote a bit about this recently

https://gavinray97.github.io/blog/design-by-contract-and-eff...

The authors cite this, but just to mention it: this sounds like F*, another proof-oriented language. (https://fstar-lang.org/)

F* is in the ML family of languages, so it looks pretty different from C*.

Names for C successor languages are pretty well exhausted by this point, so I sympathize, but I strongly associate the name C* with a decade-old rant about C compilers’ aggressive exploitation of undefined behavior: https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_20... . (In calling it a rant I don’t mean that it’s altogether unpersuasive. Its style is just a bit spicier than I am used to seeing typeset in Computer Modern.)

I like the concept of separation logic as much as the next guy, but I don't think this is it. Just look at the examples, with loop invariants alone being longer than the whole example. It's not only a problem with ergonomics, but it leaves a lot of space for specification bugs.

And I suspect that cross section of people writing C code you want to verify with formal verification folks is not particularly big.

I think formal verification is a super interesting field, but this is a non-starter for me because I do not have a backwards E on my keyboard

There already is a C* : https://en.wikipedia.org/wiki/C*

This is a competitor of ATS3.

The "C*" language website - https://cstarlang.org/en/intro.html

See in particular, usage benefits with LLMs (last para of https://cstarlang.org/en/intro.html) and how to use it with LLMs (https://cstarlang.org/en/tutorial/cstar-mcp.html).

Note that the paper/language are from 2025 and so pretty recent.

Great idea, terrible syntax.

formal verification is great and all, but you can never make it as ergonomic as functional verification. this matters for agents and real people alike.

formal verification requires a deeper understanding of underlying mechanisms to write correctly. yet nothing prevents you or your agent from changing invariants to fit the algorithm and making it incorrect.

I suspect that there is a body of C programmers out here that use C on a regular basis that aren’t posting who know that using C safely is 99% just using Valgrind and some specific GCC or llvm flags and you’re done.

They don’t reply to these threads to share that knowledge because these threads devolve into cesspools about how you should just use Rust despite the language not meeting specific requirements authors have that you have to do additional work and maintenance for in “safe” languages that you get for free in C because you don’t have to emulate it.

> I suspect that there is a body of C programmers out here that use C on a regular basis that aren’t posting who know that using C safely is 99% just using Valgrind and some specific GCC or llvm flags and you’re done.

C* (the submitted language) is not just about determining memory correctness and related program features like what Valgrind will do for you (or help with). It's about proving correctness of programs more generally, so any C programmer not looking at it because they know about Valgrind are choosing to skip something interesting for a very poor reason.

    using C safely is 99% just using Valgrind and some specific GCC or llvm flags and you’re done

I wish that were the case, but it's not. Dynamic analyzers are fantastic and everyone should be using them constantly, but they don't solve the problem of UB. They tell you whether your code, as translated by a specific compiler using a specific set of flags today has detectable problems. There are still gaps, and what's true today might not be true even for the same source code built tomorrow, or given different inputs. Asserting my safety-critical code does X or Y is important to me, and neither C nor C++ have standard tooling that fully addresses that need.

Other languages are much farther along than this. You can in theory take a pile of Rust and isolate exactly the points where undefined behavior might occur, or eliminate them entirely in Ada/Spark.

> I suspect that there is a body of C programmers out here that use C on a regular basis that aren’t posting who know that using C safely is 99% just using Valgrind and some specific GCC or llvm flags and you’re done.

Absolutely right! I sincerely hope they share their knowledge here and elsewhere.

> They don’t reply to these threads to share that knowledge because these threads devolve into cesspools

HN is often rage-inducing when it comes to comments on C/C++/Fortran/Cobol/etc. older languages and systems. There are many critical and industrial-strength systems developed by the previous generation of engineers/programmers which today's noobs/cargo-cultists cannot even hope to imagine much less understand.

As an example, people talk about all the great features provided by Erlang but forget that its BEAM VM where most of the "magic" resides is actually written in C! Imagine how much expertise lies buried in its implementation!