Hacker Newsnew | past | comments | ask | show | jobs | submit | br1's commentslogin

Formal verification should catch vibe coding bugs.


This is the entire formal verification effort, as far as I can tell: https://codeberg.org/gregburd/aether/src/branch/main/aether/...

They use TLA+ with TLC which model checks the write ahead log (a component of the system). But that only models the WAL protocol, not the actual Rust code and not the other 99% of the system.

Any formal verification is of course awesome to see though.


I have to admit I used to think any level of formal verification was worthwhile.

But I recently tried having agents try starting with formal models, and then building code using that as basis. In the end to models were never detailed enough to catch the most common issues that were shaken out with getting a high level of coverage and mutation testing.

At which point, the predictive power of the formal models became somewhat vacuous.

I’m trying to be more optimistic that maybe using dependently typed languages will yield better results.


And just because you model the system in tla+ and its a valid model doesn't mean the vibe coded implementation matches the tla+ model


The part that’s not clear to me is, does the spec actually align with what’s been implemented, or has the spec only been formally verified. I think the risk with vibe coding this sort of thing is that claude assures you the rust code implements the spec when it doesn’t


The instance profile example makes it seem like you need to specify the account for "Service": "ec2.amazonaws.com" just with another syntax, while service principals are always in the same account AFAIK.


Leapfrog Triejoin is an example of the trenches contributing to academia and academia valuing it: https://x.com/RelationalAI/status/1836115579133939752


The Unicode consortium keeps adding garbage like emojis to keep their job...


Emojis are one of the best things about Unicode. They're not even that complex to handle, and they allow sooooo many things.


You're literally responding to a comment about how some emoji were too complex to even implement, much less handle universally.


Because Chile renounced Patagonia to keep Argentina out of the war with Bolivia and Peru. Argentina is the bully around here.


The old solutions to phishing, education and weak 2fa, are in the way of the new and improved solutions, FIDO, passkeys. Nobody wants to admit that the old ways were lacking. They were hipped too hard. It's like when new health guidelines appear and contradict the old ones.


Me! waves hand in the air I admit the old ways were lacking. We just didn't have a lot of better alternatives at the time. SMS 2FA beats no 2FA. TOTP beats SMS 2FA. FIDO/passkeys/etc beat TOTP.

We've made a lot of progress as new methods and technologies have become available.


It is a somewhat 'round' number, the width of 720p resolution.


Interesting that card/drivers customize so much of ray tracing, like rasterization in pre vulkan/metal/d3d12 or even fixed function gpu days.


Exactly, it's to protect your user from you.


It would be ironic if Rust ended up killing C and not C++, being adopted into the kernel.


If I look at a list of Rust projects (awesome-rust, etc), quite a lot of them either replicate something done in C, or create something that probably would have been done in C.


To kill C++, Rust needs to grown an ecosystem for game engines, GPGPU shading languages (Metal/HLSL/CUDA), OS GUI stacks (Qt/WinUI) and composition engines,...

It might happen, in a couple of decades though.


Also, nothing is even close to matching the ability of C++ to build against other C++.

Even if Rust had Rust alternatives for enough of the interesting niches, it will take a loooong time for all the relevant software to either get rewritten or reach end of life.


Yes, a good example is that despite 40 decades of trying, there are still domains that C++ failed to take away from C.

Companies rather invest into hardware memory tagging than trying to rewrite C applications into something else, in those domains.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: