> You write the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard. Enough of it becomes noise.
As a human, I would have written something like:
> You write the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard, but it makes the code noisy.
Whether or not an LLM wrote this, it's a writing style that sounds like a politician or a sophist, and it sucks.
Cool stuff as usual, Anders. One of the nice things about running a networked DB is that it makes redeploying the application a bit simpler. You can spin up a new EC2 instance or whatever and once it's online kill the old one. That gets 0 or close to 0 downtime. If the DB is on the same instance, replacing it requires loading up the DB onto the new instance, which seems more error prone than just restarting the app on the original instance, but in my experience that typically incurs downtime or some complicated handoff logic. Have you had to deal with anything like that running sqlite in prd?
It's always frustrating to me that the order matters at all. I understand SQL can be complex to parse, but surely we are smart enough to come up with a parser that doesn't care whether FROM is before or after SELECT?
HoneySQL lets us define queries with maps, like {:select [:col1 :col2] :from :table}, and turns that into SQL. In a better world, SQL would be structured data like HoneySQL, and the strange SQL syntax we know and love would be a layer on top of that, or wouldn't exist.
As a human, I would have written something like: > You write the same plumbing for route params, request parsing, validation, and responses in handler after handler. None of it is hard, but it makes the code noisy.
Whether or not an LLM wrote this, it's a writing style that sounds like a politician or a sophist, and it sucks.