491–500 of 532 posts
Earlier quoted context omitted.
I think a lot of the time when people say the network is slow. They really mean their backend is slow. With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU). With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger. No…
> With a fast backend ~1-5ms response times (not even that fast). Even though benchmarks suggest this sort of performance should be trivial, most real-world servers I have interacted with do not reliably managed to process a request, make a roundtrip to the DB, and return a response in <5ms
Hell, for a lot of projects you don't even need to get that fancy. Run a single server with an embedde database, running Go or Java and you're good to go.
Earlier quoted context omitted.
So many developers do this, and it's infuriating. I have a device sitting there on my perfectly good LAN, yet if I want to remote control it, the brilliant software decides to send the commands to the Internet, then back to my device, then the response gets routed to the Internet, and back to my phone. Device developers, stop doing this! You people realize that LANs exist, don't you?
As I said at [1] they want to centralise it as a control point so they can monetize it. [1] https://news.ycombinator.com/item?id=49376040
LLMs have essentially made any language above the C++/Rust systems level tier obsolete. The only reason you picked a language like C# or Python is often out of convenience of having a broad ecosystem or due to the lower level languages being too hard to master, with too many footguns. The tradeoff being is that you got a less performant implement, while being easier to write. Nowadays, those arguments are dead. LLMs…
Your experience does not match mine.
It writes ok code, it does not write good code. I see it leaving a lot of performance on the table, doing silly things like wrapping everything in a global mutex. Or certainly doesn’t write idiomatic code in Rust or C++
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
"In the Hypertext Transfer Protocol (HTTP) for the World Wide Web, servers insert a MIME header field at the beginning of any Web transmission. Clients use the content type header to select an appropriate viewer application for the type of data indicated."
A fan of "let's enable the program to do everything" philosophy I am not. This idea is embodied in the so-called "modern" web browser and a countless number of other "apps". Alas, this design, perhaps justified on "convenience" grounds (or so-called "user experience"), has been abused, e.g., for commercial purposes. One casualty of the abuse might be speed. Other sacrifices might be reliability, resource usage, "privacy", "security", etc. The most important sacrifice for me in using "do everything" software is _control_
Instead I use a number of small command line clients for making HTTP requests ("web requests").^1 I can edit the source code and compile these applications quickly with low resources
The clients are request makers, not response viewers. The historical "select an appropriate viewer application" step remains, as I prefer it
This software is not slow. I seem to avoid the dissatisfaction that I see from commenters who use software that can "do everything"
1. Generally this is one application that accepts URLs on stdin and generates HTTP on stdout and another that accepts HTTP on stdin, makes connections and sends it, typically a TCP client. But since I use a local forward proxy that has a built-in httpclient I don't necessarily need those programs to make requests, e.g.,
x=https://danluu.com/perf-opt/
echo "@1;expert-mode on;httpclient GET $x"|socat stdio unix:/path/socket
Earlier quoted context omitted.
I'm still interested in your claim: > If you instead spend a day writing a proper specification, then ask the agent to spend a week implementing that, you'll need zero tools and skills afterwards to clean it up, because there won't be any misunderstandings, assumptions or other things, just code fulfilling what the specification says. Are you claiming that you reliably get good software out of agents using this proce…
> Are you claiming that you reliably get good software out of agents using this process? Yeah, for sure, I tend to be really strict about the overall design, keeping things minimal and only the abstractions needed, nothing more/less. I don't know what "most complicated software" even is, I've only been writing software for 20 years or so, but mostly around startups, smaller companies and as a consultant/freelancer fo…
Of course, all I’m saying is that you need to refine your sample! For instance: the allocation architecture is not correct, and one has to run a bunch of performance investigations and resolve it.
My responses are intending to convey that I don’t believe this is possible, no matter how good LMs get — and it seems like we are in agreement.
Wow, my browser's Reader Mode saved my bacon on this one. Otherwise, I would have left immediately. I'm all for speedy, simple, plaintext websites, but it is a negligible amount of work in 2026 to throw some barebones CSS in and make it approachable.
But reading small white text on black background that's 100% width is nearly impossible to read.
Earlier quoted context omitted.
As I said at [1] they want to centralise it as a control point so they can monetize it. [1] https://news.ycombinator.com/item?id=49376040
Developers know better, but they are overridden by management and suits. Which pays their salary, showing that doing better usually gets sidelined by doing what’s good for you.
Unpopular Opinion, but if you have absolutely zero say in the content of what you're developing, and just take orders from JIRA, you shouldn't call yourself an engineer. You should also keep your eyes open for a better job.
Earlier quoted context omitted.
I’m a lot more optimistic now that RAM is scarce. A lot of focus will be on maximizing software performance. See: iOS 27. It’s faster than the previous version, even on very old phones. I also think AI will contribute to removing a lot of the tedium surrounding optimization.
It fucking better be faster, iOS 26 basically bricked my iPhone SE, which had never been the slightest bit laggy or glitchy before that cursed update.
Earlier quoted context omitted.
I feel like I’m reading a post from 2025 instead of one written three minutes ago. People get entrenched in closedminded thinking. My guess is that this has been your canned spasm for the past year. Repeating these things won’t make them true or protect your job. You protect your job by learning how to use new tools as the technology advances. This sort of lazy thinking isn’t acceptable anymore. Whether this is a ref…
> Repeating these things won’t make them true or protect your job. Most of these things are just true as of today. > You protect your job by learning how to use new tools as the technology advances. Sure and the more you learn the more you see how hyped they were and reality untangle > Engineers don't ask a tool to write code. And what they ask? They create loops or graphs? These tools ultimately vomit code anyways