Redis has terrible durability/ consistency guarantees but people use it as a durable store. Postgres is amazing, but operating it at scale can be extremely painful, and it's obviously quite bad for numerous cases.
Why "boring" instead of "choose wisely"?
No one should be reaching for openssl. Tons of bugs, terrible APIs. But a "boring" mindset would lead you there. It's certainly the most popular library. Why not just learn about these technologies? Postgres and Redis will cause massive pain if chosen improperly.
There are so many footguns you'll run into with both of those. If you want to say "low chance of bugs", okay, but then say that and not "boring"? Why muddy your "pros" with this vague wording? What if there's a new tech with even fewer bugs? Or old tech with tons of bugs? Is openssl boring?
Make informed choices. Proxies like "boring" are just nonsense. Postgres isn't boring, it's deeply complex, evolving software. But "it's boring". Redis isn't boring, it's complex and has deeply problematic failure modes. But it's "boring".
Yes, I also hate that concept. Total nonsense imo.
Basically, LLMs do one thing really well - they run a bunch of dumb bash commands and type very very fast. Offloading technology choices to them is a huge mistake.
I'm in a position to make nuanced choices about technology, what happens to the next generation of devs? Further, IMO LLMs don't just target the average, they target below average (because I assume quality is on a power curve).
> They'll only suggest solutions that are common in their training data but those tend to be the Boring Technology that's most likely to work.
I consider this to be one of their worst qualities tbh. "Boring Technology" is a very silly idea. No such thing as "boring technology" and the limit is real
Also, like, compromised dependency? Well that's only loaded in that sandbox. No cookies, no pop-ups, no *networking* it's nuts.
It's such an aggressive move that I'd normally never be willing to pay the price for, but claude makes it trivial since it's just bespoke boilerplate every time I want to do it. XSS in the sandbox? Don't care.
I'd never have the patience for this normally, but I've had claude move basically all of my dynamic content into sandboxed iframes with strict CSPs that have to RPC back to the main page to do anything other than render content. Null origins, no networking, etc.
Someone needs to be brave and just start producing JSON parsers that produce/consume JSON with trailing commas. I don't care if everything breaks, enough is enough.
Contrast that to JS, Ruby, Python, etc, and it's not even close. A similarly sized codebase will have so many fewer stupid DoS etc, you'll link to far fewer C/C++ libs, etc. Just a hilarious way to win on a huge amount of dumb work.
Part of this is just that the Rust ecosystem is pretty solid, but the silly part is a lot of it comes down to the Rust ecosystem just not having a ton of people issuing CVEs for it.
Regardless, you benefit massively on ops overhead for a rust codebase.
A very silly but insanely significant advantage to maintaining a Rust codebase is how significantly less likely you are to get "hey please patch this completely stupid CVE" requests every day for CVEs that aren't even valid.
Switching hash algorithms in Rust is such an easy win. 40% performance improvement on one of my project's benchmarks.
Letting this guy run a CNA is the biggest fuckup the CVE system as managed so far, which says a lot.
Decades later and Linux security is still a fucking joke; www.kroah.com/log/blog/202...
I've never seen people say this but I'm not on LinkedIn/Twitter. Do you have a reference for that?
If you can go lower, do it. Even if you don't go down to 2^16, it's still beneficial to say "I only use 2^22 of 2^32 values" and now you have 10 bits to play with for all sorts of fun tagging. 10 bits is a lot.
Literally 1000s of times faster for so many operations, with 10x space savings easily, and even better if you can shave a few bits off.
Absolutely insane what kind of performance opportunities there are when you replace strings with integers. Especially 32bit integers.
I also have meta agents with their own rules. These check that the other agents are working effectively, with a sort of meta benchmarking suite that will fail if the other agents aren't performing the requisite tasks. Every agent has 1+ JSON files that they get verified against and a fail threshold.
Notably, I've set things up so that verification is at the absolute core. *Everything* is verifiable. Playwright tests, benchmarks, tons of logs and metrics that the agents all have the ability to call into, pre-commit hooks that force behaviors, etc.
There's these very uncomfortable periods where the gap exists but so far it hasn't been a problem, despite this being my most aggressively vibe coded project ever. I'm learning to not feel so nervous, and I'm learning a lot tbh. Those times where I sync up are very interesting.
There are times where I'm genuinely like "oh shit idk how that works". But... it hasn't been a problem. When I iterate on the design to push to the next limit, well, I sync with the agent. I have it tell me all about it. That's when I learn how it works, and then I steer it forward again.
I recently set up a project in a very "Vibe First" way. Like, mostly I have an agent specify cursor rules, write out goals, designs, etc. Then a bunch of agents go off into git worktrees. I was very concerned by this issue, and my experience is that it "ebbs and flows".
LLMs are definitely going to kill HN. I don't see how it'll survive with the bots signing up.
Very frustrated again that the best algorithm that's available with FIPS is AES-256-GCM. I really dislike this.
do i know anyone who works at azure that can get me access to horizondb? i can elaborate more in dms if needed.
