Trust in formal reasoning is necessarily always conditional. You have to start somewhere. The good thing about verified formal proofs is that the only way they can be in error is if the verifier is faulty. This drastically limits the possible reasons for error.

(In practice, there’s also the possible error that the proved formal statement means something different than what you thought it meant.)

One can only trust a verifier as far as they can trust anything made out of software.

It has nothing to do with LLMs. One cannot trust the proof of anything if one cannot trust the verifier.

I would expect proofs that exploit kernel bugs to look fishy, so someone reading the proof could catch the smell.

That said, I'm sure there's also room for underhanded Lean programming as well, which would be even more interesting.

from the article:

> With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms.

this is what the big deal is. it might not achieve much on its own immediately, but this is the key to build a truly multiplatform ecosystem of libraries, tools and applications in Swift. we should expect to see more of that soon.

Since it’s not clear from the title: embedded here does not mean sqlite-inside-your-app but small devices with microcontrollers

That's what I initially thought too, though having read and understood little of the article, is sqlite not a consideration too? Or does it take up too much memory?

There's a pretty good write up on running sqlite on an STM32 here: https://github.com/luismeruje/SQLite-STM32

Keeping in mind that STM32 is on the high end of what you might call embedded, and the writeup is pretty clear that it barely fits/works there, lots of caveats, etc.

Another thing to consider is that sqlite dynamically allocates memory. You typically want to avoid that in embedded. Everything is slow, memory is scarce. The sheer code size is also a issue.

Sqlite has a mode where you can give it an area of memory and it will never use any other memory.

It's still going to dynamically allocate its memory in there, isn't it? This is a slow operation.

Memory allocation isn’t that slow (in fact all the ram is SRAM which is typically quite fast), it’s just that you only have 256k-1M RAM in total. This means that any time you’re saving later by trying to fill space now ends up getting wasted when that memory needs to be reclaimed.

SQLite would require a file system. Embedded systems typically do not have this.

SQLite doesn’t require a file system per se, as you can create an in-memory db and then use vfs to load/write the actual data from/to your IO layer.

Though note you can define your own "Virtual File System" (VFS) for SQLite to use[1]. It might be a bit of an undertaking, but I think you could use that to run on just about anything with storage you control. (I haven't done it myself, just some research back in the day)

[1] https://www.sqlite.org/c3ref/vfs_find.html

Very interesting to see that Clang basically always produces very bad and unoptimized LLVM IR code and leaves it to LLVM to clean it all up. That said, it's not entirely true that Clang avoid doing any optimizations -- it does indeed produce slightly different LLVM IR for -O0 and -O3.

I think this was done because while LLVM was built to be academic, Clang was built to be fast and beat GCC, and so ended up overly low level.

A nicer and newer approach is to use an intermediate bytecode that lowers to LLVM IR; Swift, GHC, and I'm sure several other examples I haven't thought of do this.

I'd like to see this for C because I think -O0 is a bad debugging experience, eg because system libraries are still optimized, and an interpreter running on a C-like bytecode would be better. Really the only thing -O0 is good for is working around compiler bugs.

they even show this in the video, apparently it’s supposed to be straightforward