Live data from Hacker News

There's no reason for software to be slow anymore

danluu.com

501–510 of 531 posts

Re: There's no reason for software to be slow anymore

#501

Earlier quoted context omitted.

The reason for using Electron is to write once and run everywhere right? I get that LLMs would make it faster to write distinct copies for different operating systems and maintain them both but thats still more costly than a single system. Sorry if I’m misunderstanding the goal of Electron but it still seems cheaper and easier (although admittedly worse than multiple native apps)

Yeah that's my point. Maybe AI will lower that cost to the point where it makes sense to write e.g. a native Slack app. I dunno, we'll see.

There is a native Slack client actually. Fast and with good feature coverage, it’s called msga.app

Re: There's no reason for software to be slow anymore

#502
post #496

Earlier quoted context omitted.

> 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…

Okay, so we’re using the same process — but your original message seemed to imply a sort of one shot no refinement iterations — which is what I was responding to as unrealistic (e.g. make a spec let goal run artifact is perfect) 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 resolv…

We're mixing two different things here though. You're saying that you would need to correct the compiler because the agent did wrong, I'm saying that you'll need to correct the compiler because your specification will be wrong. The agent does the correct thing, but the correct thing was wrong in some way, if that makes sense?

If your goal with building this compiler was performance, and this wasn't part of the initial specification, and the agent didn't assume it had to, is this what you're saying is a failure on the agents side?

There is no distribution to fight, is my hypothesis at least, if you're just a lot more clear exactly what you expect up front. Hence the whole "To correct those behaviors, you're going to write tools and skills" thing isn't even needed in the first place.

Re: There's no reason for software to be slow anymore

#503
post #44

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…

To dogfood this, rent a VPS in Australia and put a test environment there. Should be about 200ms ping or a bit higher. How it runs for you is how Australian users are seeing your site, even if their last mile connection is fiber.

Example pings from here in Australia (FTTP)

  PING news.ycombinator.com (209.216.230.207): 56 data bytes
  ...
  --- news.ycombinator.com ping statistics ---
  40 packets transmitted, 40 packets received, 0% packet loss
  round-trip min/avg/max = 154.980/155.832/156.990 ms
FTTP except via WiFi:

  round-trip min/avg/max = 164.218/164.860/165.764 ms
Or through the mobile network:

  rtt min/avg/max/mdev = 201.881/245.543/350.600/48.713 ms

Re: There's no reason for software to be slow anymore

#504

Earlier quoted context omitted.

I have a new laptop with a rtx 5090. Opening any GL context takes more than half a second. There's tons of things that can be optimized and are pretty far from web.

I assume you're running proprietary drivers? Because I've never experienced anything like that on mesa. Launching an app that opens a window with a gl or vk context is so fast on my almost 10 year old hardware that it's nearly imperceptible.

I had this problem on Fedora and my RTX 3090. Never got to the bottom of it.

Re: There's no reason for software to be slow anymore

#505

Earlier quoted context omitted.

Sonos’ app is another example of this. As a very brief tl;dr if anyone isn’t aware of it, Sonos is a wireless speaker company that can group speakers in different rooms into zones, so you can have different music playing in different rooms, or all the same, or at different volumes, etc. The quality isn’t going to blow away audiophiles, but IMO they’re legitimately great. The original design had the speakers setting u…

wow really? is this only for newer speakers or do older gen speakers work this way too

The older speakers are stuck on an older version of the app (it’s a wholly different app, called S1) which doesn’t have that behavior AFAIK.

Re: There's no reason for software to be slow anymore

#506

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.

I have a large and varied experience of “developers”. The majority aren’t any more morally virtuous than a brick. They wake up, get down to the sausage factory and make sausages.

Again this is mostly our biases playing us. Within HN and similar communities there are a lot of above average and caring developers. Those who don’t care aren’t going to be here to look like they do.

Re: There's no reason for software to be slow anymore

#507

Earlier quoted context omitted.

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.

I'm not letting the developers entirely off the hook. At many companies, they are decision makers too, and partially share the blame with their product leadership and other decision makers. 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.

Agreed. Plus, if you can get an entire team to tell the PM “this is fucking stupid, we aren’t doing it,” what are they gonna do - axe an entire team? I doubt it. Maybe at big companies, but small ones? Nah.

Re: There's no reason for software to be slow anymore

#508

No there's a simple reasons actually: we have surrendered entirely to web based apps & the resulting ad bloat. You used to buy a computer, install an OS, buy apps and run them. Neither the OS nor the apps didn't suddenly degraded themselves with "free update" that were developed targeting newer & newer machines. You bought a new computer when new software you wanted to buy wouldn't run fast enough on it, OR the compu…

> Nowadays, you buy a new computer when the same software you've been running for years or the OS itself that demands to be updated "free" makes your machine intolerably slow. This is, in my experience, not a thing on Linux.

Sort of a thing on linux (and bsd) but not as often. An example is the mostly end of 32-bit computing, since 64-bit computing requires far more resources/RAM (arguably, some of that can be ameliorated with swapping, but it is wayyy less good).

Or the way so many people were on netbooks and the growing monolithic kernel kind of made the default gig or two of RAM less and less doable (I guess non-consumer-modifiable tablets and mostly soldered and increasingly locked down chromebooks took over most of that market, but it feels like people just take storage space, memory management, and hardware for granted, now).

Re: There's no reason for software to be slow anymore

#509

Earlier quoted context omitted.

If your app absolutely must rely on the cloud for every one of its interactions, then fine. If not, you're just applying band-aids to a problem of your own making. Many apps could easily be local only, or local first. If you're not constantly accessing the network for information which could be stored locally, then you don't need to hide your app's slowness behind animations.

Canva replaced PowerPoint. Canva is cloud based and PowerPoint is not. There's so many apps that are cloud only so that corporate it no longer has to manage installations and users don't need to ask IT for permission anymore. I think SaaS doesn't really work without the cloud, you could technically do what adobe does but why bother with app distribution and windows' quirks. Cloud based web apps are write once, run an…

I'm not familiar with Canva but I don't see any technical reason why every interaction would need to rely on the server. Since Canva uses client-side JavaScript, it could be designed so that the local version of a document updates immediately and the cloud version syncs with the local version as soon as possible.

I would guess Canva already does something like this.

Re: There's no reason for software to be slow anymore

#510
post #460

I was having this exact thought after I overheard a conversation on a train, where two developers were discussing the quality of TypeScript being generated by Claude Code, and how they were getting closer and closer to having all of the architectural requirements, test cases, etc. in place to be able to one-shot correct and functional TypeScript. But if you're going to be relying on the LLM to do all the final-stage…

> why would you still target TypeScript, which is entirely a kludge to shoehorn type safety into JS for the benefit of human programmers? To help the hapless humans who have to fix it, silly!

Yeah this logic assumes humans never need to read, edit, or understand the code.

Maybe we’ll get there but I don’t think we’re there yet.

I still regularly run into bugs that agents struggle to solve.

And they often churn creating more and more convoluted solutions which are then more error prone and harder to reason about

Post reply on HN