Comment by est31
14 hours ago
Also you would probably want to cache the compiler's output in git because running that compiler would take a long time, and you probably want the compiler's output to still be inspectable to human inspection. In the end that compiled artifact would look a lot like source code.
I think Rust's success in the AI space shows how useful formal proofs are, as Rust provides something very similar to that. Both because it helps with the understanding of LLMs, as well as with trusting the LLMs are not violating any basic properties (like please no nasal demons if the user sends a buffer larger than the allowed amount).
``` SELECT A, B, Sum(C) FROM Somewhere GROUP BY ALL ```
Very few developers look at the underlying “source code” that this SQL compiles into. Very few people even read the “source code” that tsc outputs.
The reality is the lowest level checkpoint worth looking at and understanding is the highest possible abstraction layer which preserves 100% of the needed precision and flexibility that the product being built requires.
Also, you’d just use something like sscache or just .o files to speed up compilation. It’d be unusual to store compiler MIR/LIR in git.
I think the important part will be figuring out what we need from the higher level language that achieves 100% of the precision and flexibility of Rust for the product being built.
> Very few developers look at the underlying “source code” that this SQL compiles into. Very few people even read the “source code” that tsc outputs.
Only because there’s a group of people that do understand database theory and know how to write a proper implementation and they have a track records of doing so. Themselves relies on compilers maintainers and OS developers, and this goes on down to the semiconductors where people do study how electricity interact with the materials.
Every layers of the tower of abstractions have people that understand the current layers, knows the safe semantics of the layer below, and can provide a safe foundation for the layer above.
> formal proofs are, as Rust provides something very similar to that
Since when? Rust just has an ML-like type system, and seemingly many have met that for the first time with Rust, even though it has decadeS of history, and multiple production languages running it just fine (ocaml, scala, etc).
Formal proofs are way way above an ML type system. Like how do you encode mathematical statements in Rust's type system? What about statements about program semantics, like program A is equivalent to program B <- in formal verification THAt is the type of an expression, and the implementation of it is the proof.
By similar i meant the strong and powerful type system that Rust has, plus its safety guarantees (iterator invalidation is a compiler error etc). That is in the end a proof system: you are proving to the compiler that you really don't mutate the buffer and you can't drop the T in &T, etc.
Of course the Rust language doesn't give you tools to prove that the program is bug-free or such. The proofs only extend to a basic set of properties, but there is a proof system in Rust.
As for other ML languages, they aren't really C/C++ competitors performance wise, Rust is.
We've got inform7 with an English like language generating complex inform6 OOP optimized code since a few decades and the i7 compiler might even run under a Pentium II with 128MB of RAM under NetBSD. I6, under 32 and a Pentium. And maybe even less. ZMachine games themselves (the biggest v8 ones) under the Frotz interpreter, under a 486 and 8MB (with FreeDOS and Frotz). Or maybe an Amiga or a m68k Mac with the same amount of RAM.
Now imagine what AMD64 machine can do with 2GB of RAM (minimum baseline for legacy, maybe some C2D computer) today.
inform7 is closer to a dsl than a general purpose language. We might be looking at something closer to spark/ada.