jstrong

but did they change the process-per-connection model? if not, wtf??

seems like `cargo nextest run` just runs `--lib` tests by default? however, `cargo test` is not so slow if you do `cargo test --lib`. how do I get nextest to execute the doc tests, too?

hoping this is a joke

claude is so slow for interactive use like described, do people just run it in low effort mode or what?

optimizer can't inspect the value? pretty dumb optimizer, then.

that's A choice.

I feel like the less tolerance I have for ads (as time goes on), the more desperate they get in trying increasingly aggressive ways of making you watch ads. I'm never watching ads again, ever! I'm willing to pay, but not with my time for your terrible, horrendous, bullshit ads!

I don't know, man, glossy magazine ads were glamorous. sure there was stupid stuff, but the comparison between the "one weird trick" era and magazine ads of someone looking cool so you have a positive impression with some brand name is pretty stark.

man, I can't wait to wrangle a giant YAML file to be able to take a sick day!

redis is single-threaded but handles lots of connections (i.e. > 500) with much better performance vs. postgres. there's zero chance someone building postgres in 2025 would do one process per connection, I don't think there's any argument that it's a good design for performance. it's just a long-ago design choice that would be difficult to change now.

From the article:

> The real bottleneck is the single-threaded main loop in the postmaster.

A single-threaded event loop can do a lot of stuff. Certainly handle 4000 tasks of some sort in under 10s. Just offhand it seems like it would be eminently possible to handle incoming connections on the scale they describe in a single-threaded event loop.

Clearly the existing postgres postmaster thread is a bottleneck as it is implemented today. But I'd be interested to go deeper into what it's doing that causes it to be unable to keep up with a fairly low workload vs. what is possible to do on a single thread/core.

can't believe postgres still uses a process-per-connection model that leads to endless problems like this one.

google: we make going to the DMV look delightful by comparison!

ripgrep is one of the main reasons I got interested in rust. it worked so well, it piqued my interest that it was written in rust. many years later, very glad about that. been using `rg` daily since then as well!

... some stuff we have kinda resembles china's social credit score if you really think about it ...

ok, maybe

... so yeah, it's totally fine lets do it ...

WHAT

imagine some people started using hammers as weapons, leading to some gruesome murders vividly depicted by the news. as a result, construction companies started advertising that this house was built without the use of ANY hammers. that's how I feel about cookies.

cookies are not the problem. spyware is the problem. the way cookies work is, the server includes a "SET-COOKIE" header in its response. it is literally a request, which has no power, other than your computer deciding to store the data locally and include the cookie as a header in its subsequent requests.

somehow instead of us collectively relying on our own user agents to not comply with requests from remote servers that are not in our interest, we settled on deciding the cookie itself is a dangerous mechanism, which is stupid.

wow that sounds like a PITA to deal with

was expecting to see examples of python tests you would use, presumably for testing the rust code? like, how would writing the tests in python be easier?

a man can dream

I would like a workstation with 900k cores. lmk when these things are on ebay.

man, the python examples in there .. I am always low-grade irked by those! until now I wouldn't have been able to describe the problem. great piece.

unrelated rant, but I'm still salty about it.

needed to send "raw" http requests instead of using their bloated sdk for reasons, and requests failed with "content-type: application/json" header, but succeeded with "content-type: application/x-amz-json-1.0". get out of here with that nonsense.

like you I'm more open to the idea of keeping data in memory than most of the responders here. when I got to the part of the article about how they are using common lisp with hot reloading, I was thinking, well you guys can do whatever you want, but not everybody is working on that team, ha.

enjoyed the article - provides a comprehensive tour of the benefits of deploying in a tmux session (seamless restarts via ctrl-c, up, enter). for super important stuff, a systemd unit is worth considering.

in terms of comparing to numpy, how much overhead would there be from Python (vs. running the numpy C code alone)?

I don't think if I had $2 billion in proceeds from a piracy website I would choose to reside in Germany.

I need this to resist the temptation to read the HN comments on politics, ha.

people voted with their life decisions and it turns out your view is not very popular.

greatly enjoying your humor