We use pgmq with the pgmq-go client, and it has clients in many different languages, it's amazing.
The queues persist on disk and visualizations of queues can easily be made with grafana or just pure sql requests.
The fact that the queues lives in the same database as all the other data is also a huge benefit if the 5-15ms time penalty is not an issue.
At least until people - in a couple of years - figure out that the "Postgres for everything" fad was just as much of a bad idea as "MongoDB for everything" and "Put Redis into everything".
It's not "Postgres for everything", it's "Postgres by default". Nobody is saying you should replace your billion-message-per-second Kafka cluster (or whatever) with Postgres, but plenty of people are saying "don't start with a Kafka cluster when you have two messages a day", which is a much better idea than "MongoDB by default".
I'm vibe coding now, after work. I am able to much more quickly explore the landscape of a problem, get into and out of dead ends in minutes instead of wasting an evening. At some point I need to go in and fix, but the benefit of the tool is there. It is like a electric screwdriver vs. normal one. Sometimes the normal one can do things the electric can't, but hell if you get an IKEA deliver you want the electric one.
0. Claude, have a look at frontend project A and backend project B.
1. create a skeleton clone of frontend A, named frontend B, which is meant to be the frontend for backend project B, including the oAuth configuration
2. create the kubernetes yaml and deployment.sh, it should be available under b.mydomain.com for frontend B and run it, make sure the deployment worked by checking the page on b.mydomain.com
3. in frontend B, implement the UI for controller B1 from backend B, create the necessary routing to this component and add a link to it to the main menu, there should be a page /b1 that lists the entries, /b1/xxx to display details, /b1/xxx/edit to edit an entry and /b1/new to create one
4. in frontend B, implement the UI for controller B2 from backend B, create the necessary routing to this component and add a link to it to the main menu, etc.
etc.
All of this is done in 10 minutes. Yeah I could do all of this myself, but it would take longer.
Did you need it though? Like most projects I see being done by people with Claude Code are just their personal projects, which they wouldn't have wasted their time on in the past but now they will get pulled into the terminal thinking its only gonna take 20 mins and they end up burning 100s of subscription dollars on it. If there is no other maintainer & the project is all yours, I dont see any harm in doing it.
I don't NEED this, but turning 2-3 hours fiddling with DTOs, kubernetes yaml, dockerfiles, deployment scripts and other busy work into half an hour does "save you the whole evening" (which our current discussion is about!).
With adults usually having no more than 2-3 hours of free time per work day, this allows you to productively program in your free time without fully burning out.
Also, my company pays for claude and does not give a shit what I do with it.
He brushes over the zoom out, which I think was pretty impressive for a computer of this time. There is a lot of redrawing/recalculating going on there. Would be impressive on a 80s microcomputer.
No, rendering to a vector display (hardware whose primitive operations are points and lines) is almost free for the kind of drawings he was rendering. Zoom is just one linear transformation on each point in the model, no different from panning the view.
My school didn't have a domain name or even an email address, or even an internet connection. I think it had 1 or 2 BBC Micros though. I remember playing a game where you had to fire a cannon (choose angle and power) and hit something. Funny how memory works - I assumed I'd remember nothing as so long ago, but remember sitting in the room playing that game now, can't remember why I could though (why I had free access).
Based on the age of the bbc micro, no way it was scorched earth, tanx seems likely (I think it was 3d tanx? I have a vague memory of seeing this in a vintage collection)
Yeah even on HN not everyone got to the real issue. It is not so obvious unless you have done SRE or like me just have to do oncall and have to do some SRE for your services. The obvious take is "there is a bug at line X" and especially with it being Rust the tempting lol Rust code is buggy it was meant to be safe. But code will have logical bugs so you need to know how to deal with that uncertainty in deployments.
RE Linkedin - it's a good filter, see some BS post, add it to a list, then when you need a job and want to choose your boss, or when you want to hire someone, you have a filter :-). Maybe 3 strikes to allow for an honest mistake or something that looks like AI but turns out it wasn't.
reply