Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes.
I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 minutes to do what would have taken a day", but then I thought, "maybe it was 20 minutes for 4 hours worth of work". The next day I looked at it and found the logic was convoluted, it tried to write good error handling but didn't succeed. I went back and forth and ultimately wound up recoding a lot of stuff manually. In 5 hours I had it done for real, certainly with a better test suite than I would have written on my own and probably better error handling.
As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my pocket, then do a code review some time later. This process is very low mental overhead for me, so it's a big productivity win.
The cost is in the context switching. Throw 3 tasks that came 15, 20 and 30 min later. The first is mostly ok, you finish by hand. The second have some problems, ask for a rework. Then came the other and, while ok, is have some design problems. Ask another rework. Comes back the second one, and you have to remember the original task and what things you asked for change.
I've already written about this several times here. I think the current trend of LLMs chasing benchmark scores are going in the wrong direction at least as programming tools. In my experience they get it wrong with enough probability, so I always need to check the work. So I end up in a back and forth with the LLM and because of the slow responses it becomes a really painful process and I could often have done the task faster if I sat down and thought about it. What I want is an agent that responds immediately (and I mean in subseconds) even if some benchmark score is 60% instead of 80%.
Programmers (and I'm including myself here) often go to great lengths to not think, to the point of working (with or without a coding assistant) for hours in the hope of avoiding one hour of thinking. What's the saying? "An hour of debugging/programming can save you minutes of thinking," or something like that. In the end, we usually find that we need to do the thinking after all.
I think coding assistants would end up being more helpful if, instead of trying to do what they're asked, they would come back with questions that help us (or force us) to think. I wonder if a context prompt that says, "when I ask you to do something, assume I haven't thought the problem through, and before doing anything, ask me leading questions," would help.
I think Leslie Lamport once said that the biggest resistance to using TLA+ - a language that helps you, and forces you to think - is because that's the last thing programmers want to do.
World of LLMs or not, development should always strive for being fast. In the LLM World, users should always have the controls on accuracy Vs speed. (Though we can try for improving both and not one way or other). For eg at rtrvr.ai we use Gemini Flash as our default and did benchmarking on flash too with 0.9 min per task in the benchmark still yielding top results. That said, I have to accept there are certain web tasks on tail end sites that needs pro to accurately navigate at this point. This is the limitation given our reliance on Gemini models straight up, once we move to our models trained on web trajectories this hopefully will not be a problem.
If using off the shelf LLMs always have a bottleneck of their speed.
The only thing I've found that LLM speeds up my work is a sort of advanced find replace.
A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever"
It has been pretty decent at these types of changes and saves time of poking though and finding all the places I would have updated manually in a way that find/replace never could. Though I've never tried this on a huge code base.
I supposed you haven’t tried emacs grep mode or vim quickfix? If the change is mechanical, you create a macro and be done in seconds. If it’s not, you still got the high level overview and quick navigation.
I guess it depends? The "refactor" stuff, if your IDE or language server can handle it, then yeah I find the LLM slower for sure. But there are other cases than an LLM helps a lot.
I was writing some URL canonicalization logic yesterday. Because we rolled this out as an MVP, customers put URLs in all sorts of ways and we stored it into the DB. My initial pass at the logic failed on some cases. Luckily URL canonicalization is pretty trivially testable. So I took the most used customers from our DB, send them to Claude and told Claude to come up with the "minimum spanning test cases" that cover this behavior. This took maybe 5-10 sec. I then told Zed's agent mode using Opus to make me a test file and use these test cases to call my function. I audited the test cases and ended up removing some silly ones. I iterated on my logic and that was that. Definitely faster than having to do this myself.
All the references to LLMs in the article seemed out-of-place like poorly done product placement.
LLMs are the anti-thesis of fast. In fact, being slow is a perceived virtue with LLM output. Some sites like Google and Quora (until recently) simulate the slow typed output effect for their pre-cached LLM answers, just for credibility.
Eeeh, I spend less time writing code, but way more time reviewing and correcting it. I'm not sure I come ahead overall, but it does make development less boilerplaty and more high level, which leads to code that otherwise wouldn't have been written.
That sounds plausible if the senior did lots of simple coding tasks and moves that work to an agent. Then the senior basically has to be a team lead and do code reviews/qa.
I switch to vs code from cursor many times a day just to use their python refactoring feature. The pylance server that comes with cursor doesn't support refactoring.
Early in my career as a software engineer, I developed a reputation for speeding things up. This was back in the day where algorithm knowledge was just as important as the ability to examine the output of a compiler, every new Intel processor was met with a ton of anticipation, and Carmak and Abrash were rapidly becoming famous.
Anyway, the 22 year old me unexpectedly gets invited to a customer meeting with a large multinational. I go there not knowing what to expect. Turns out, they were not happy with the speed of our product.
Their VP of whatever said, quoting: "every saved second here adds $1M to our yearly profit". I was absolutely floored. Prior to that moment I couldn't even dream of someone placing a dollar amount on speed, and so directly. Now 20+ years later it still counts as one of the top 5 highlights of my career.
P.S. Mentioning as a reaction to the first sentence in the blog post. But the author is correct when she states that this happens rarely.
P.P.S. There was another engineer in the room, who had the nerve to jokingly ask the VP: "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?". They didn't laugh, although I thought it was quite funny. Hey, Doug! :)
> "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?"
I don't get it. Wouldn't going from 1 second to 0 seconds add the same amount of money to the yearly profit as going from 2 seconds to 1 second did? Namely, $1M.
> I don't get it. Wouldn't going from 1 second to 0 seconds add the same amount of money to the yearly profit as going from 2 seconds to 1 second did? Namely, $1M
Of course the joke was silly. But perhaps I should have provided some context. We were making industrial automation software. This stuff runs in factories. Every saved second shrinks the manufacturing time of a part, leading to increase of the total factory output. When extrapolating to abusrd levels, zero time to manufacture means infinite output per factory (sans raw materials).
yeah it's one of those things that are funny to the people saying it because they don't yet realize it doesn't make sense. I bet they felt that later, in the hotel room, in the shower, probably with a bottle of scotch.
Working with a task scheduling system, we were told that every minute a airplane is delayed costs $10k. This was back in the 90s, so adjust accordingly.
Unfortunately, there wasn't a single bottleneck. A bunch of us, not just me, worked our asses off improving performance by a little bit in several places. The compounded improvement IIRC was satisfactory to the customer.
They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++".
Watch HN for a while and you'll start to notice that "fast" is the only feature that is necessary to win over mindshare. It is like moths to a flame as soon as something says it is faster than what came before it.
Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save
GitHub Desktop is way better for reviewing diffs than the git cli. Everyone I’ve ever worked with who preferred cli tools also did an add and commit everything, and their PRs always have more errors overall that would be caught before even being committed if they reviewed visual diffs while committing.
You're taking the wrong conclusion, "Fast" is a winning differentiator only when you offer the same feature-set, but faster.
Your example says it, people will go, this is like X (meaning it does/has the same features as X), but faster. And now people will flock from X to your X+faster thing.
Which tells us nothing about if people would also move to a X+more-features, or a X+nicer-ux, or a X+cheaper, etc., without them being any faster than X or even possibly slower.
I hate it but it's true. Look at me, my fridge as an integrated tablet that tells me the weather outside. Never mind that it is a lil louder and the doors are creaky. It tells me the weather!
Maybe for languages, but fast is easily left behind when looking for frameworks. People want features, people want compatibility, people will use electron all over.
> fast is easily left behind when looking for frameworks.
Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day.
> People want features, people want compatibility
Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into "Hold up. What I'm currently using actually sucks. I'd better reconsider."
"Fast" is deemed important, but it isn't asked for as it is considered inconceivable that you wouldn't always make things "fast". But with that said, keep in mind that the outside user doesn't know what "fast" is until there is something to compare it with. That is how some products can get away with not being "fast" — until something else comes along to show that it needn't be that way.
And yet we live in a world of (especially web) apps that are incredibly slow, in the sense that an update in response to user input might take multiple seconds.
Yes, fast wins people over. And yet we live in a world where the actual experience of every day computing is often slow as molasses.
The trouble is that "fast" doesn't mean anything without a point of comparison. If all you have is a slow web app, you have to assume that the web app is necessarily slow — already as fast as it can be. We like to give people the benefit of the doubt, so there is no reason to think that someone would make something slower than is necessary.
"Fast" is the feature people always wanted, but absent better information, they have to assume that is what they already got. That is why "fast" marketing works so well. It reveals that what they thought was pretty good actually wasn't. Adding the missing kitchen sink doesn't offer the same emotional reaction.
Molasses can be fast if you leave it in the packet and hurl it!
Seriously though, you're so right- I often wonder why this is. If it's that people genuinely don't care, or that it's more that say ecommerce websites compete on so many things already (or in some cases maintain monopolies) that fast doesn't come into the picture.
To a first approximation HN is a group of people who have convinced themselves that it's a high quality user experience to spend 11 seconds shipping 3.8 megabytes of Javascript to a user that's connected via a poor mobile connection on a cheap dual-core phone so that user can have a 12 second session where they read 150 words and view 1 image before closing the tab.
Fast is _absolutely not_ the only thing we care about. Not even top 5. We are addicted to _convenience_.
The fact that this article and similar ones get upvoted very frequently on this platform is strong evidence against this claim.
Considering the current state of the Web and user application development, I tend to agree with regard to its developers, but HN seems to still abide by other principles.
It's not that they convinced themselves, but that they don't know how to do any better. It is as fast as it can be to the extent of their knowledge, skill, and ability.
You see some legendary developers show up on HN from time to time, sure, but it is quite obvious that the typical developer isn't very good. HN is not some kind of exclusive club for the most prestigious among us. It is quite representative of a general population where you expect that most aren't very good.
This kind of slop is often imposed on developers by execs demanding things.
I imagine a large chunk of us would gladly throw all that out the window and only write super fast efficient code structures, if only we could all get well paid jobs doing it.
It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project".
In response, Casey spent <1 week making RefTerm, a skeleton proto-terminal with the same constraints Microsoft people had - using Windows APIs for things, using DirectDraw with GPU rendering, handling terminal escape codes, colours, blinking, custom fonts, missing font character fallback, line wrap, scrollback, Unicode and Right-to-Left Arabic combining characters, etc. RefTerm had 10x faster throughput than Windows Terminal and ran at 6-7000 frames per second. It was single-threaded, not profiled, not tuned, no advanced algorithms, no-cheating by sending some data to /dev/null, all it had to speed it up was simple code without tons of abstractions and a Least Recently Used (LRU) glyph cache to avoid re-rendering common characters, written the first way that he thought of. Around that time he did a video series on that YouTube channel about optimization and arguing that even talking about 'optimization' was too hopeful, we should be talking about 'not-pessimization', that most software is not slow because it has unavoidable complexity and abstractions needed to help maintenance, it's slow because it's choked by a big pile of do-nothing code and abstraction layers added for ideological reasons which hurt maintenance as well as performance.
This video[2] is another specific details one, Jason Booth talking about his experience of game development, and practical examples of changing data layout and C++ code to make it do less work, be more cache friendly, have better memory access patterns, and run orders of magnitude faster without adding much complexity and sometimes removing complexity.
I simultaneously love and hate watching Casey Muratori. Love because he routinely does things like this, hate because I have conversations like this entirely too often at work, except no one cares.
Someone posted their word game Cobble[1] on HN recently, the game gives some letters and the challenge is to find two English words which together use up all the given letters, and the combined two words to be as short as possible.
A naive brute-force solver takes the Cobble wordlist of 64k words and compares every word against every other word and does 64k x 64k = 4Bn loops and in the inner loop body, loops over the combined characters. If the combined words average 10 characters long, that's 40 billion operations just for the code structure, plus character testing and counting and data structures to store the counts. Seconds or Minutes of work for a puzzle that feels like any modern computer should solve it in microseconds.
It's always mildly intresting to me how a simple to explain problem, a tiny amount of data, and four lines of nested loop, can generate enough work to choke a modern CPU for minutes. Then considering how much work 3D games do in milliseconds. It highlights how impressive algorithmic research of the 1960s was to find ways to get early computers to do anything in a reasonable time, let alone find fast paths through complex problem patterns. Or perhaps, of all the zillions of possible problems which could exist, find any which can be approached by human minds and computers.
Of course finding the optimal solution to a Cobble puzzle does not actually require the computation you describe. We can in a single pass find a limited set of candidate words and work out a solution with those.
I would have loved to live in a universe where we could replace the Windows Terminal with RefTerm - if only, to measure how many hours would pass before a Fortune 500 company has to halt operations, because RefTerm does not properly re- implement one of the subtle bugs creeping from one of the bazillion features that had made WinTerm slow over the years. [1]
I sighed when I read your comment, a comment which is exemplary of what Casey Muratori was ranting against - casual lazy dismissal of the idea that software can be faster, based on misunderstanding and lack of knowledge and/or interest, and throwing out the first objection that comes to mind as if it's an impassable obstacle. There were no bazillion features that made WinTerm slow over the years because Windows Terminal was a new product for Windows 10, released in 2019.[1]. There were piles of problems in Windows Terminal, Casey calls out that it didn't render Right-to-Left Arabic combining glyphs and it wasn't a perfect highly polished program from the outset. And it was an optional download, Fortune 500s wouldn't run it if they didn't want to.
RefTerm was explicitly not a production quality terminal and was not intended to be a replacement for Windows Terminal. RefTerm was a lower bound for performance of an untuned single-thread terminal. RefTerm was a proof of concept that if Microsoft had spent money and engineering skill on performance they could have profiled and used fancy algorithms and shortcuts and reimplemented slow Windows APIs with faster local ones, used threading, and improved on RefTerm's performance. A proof that "significantly faster terminals are unrealistic" is not true, that all the casual dismissals of why it's impossible are not the reasons for slowness, and that 10x better is an easily achievable floor, not a distant unreachable ceiling.
As a result of Casey's public shaming, Windows Terminal developers did improve performance.
Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast.
I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossible for me to skim the comments.
I think I tried it for about 3 days before I gave up, and I was a daily Slashdot reader before then.
bonus, these have both http & https endpoints if you needed a differential diagnosis or just a means to trip some shitty airline/hotel walled garden into saying hello.
I usually load my blog to check internet connectivity.
I work at an e-waste recycling company. Earlier this week, I had to test a bunch of laptop docking stations, so I kept force refreshing my blog to see if the Ethernet port worked. Thing is, it loads so fast, I kept the dev tools open to see if it actually refreshed.
The HN UI could do with some improvements, especially on mobile devices. The low contrast and small tap areas for common operations make it less than ideal, as well as the lack of dark mode.
I wrote my take on an ideal UI (purely clientside, against the free HN firebase API, in Elm): https://seville.protostome.com/.
To each their own, but I find the text for the number of points and "hours ago" extremely low contrast and hard to read on your site. More importantly, I think it emphasizes the wrong thing. I almost never really care who submitted a post, but I do care about its vote count.
Information density and ease of identification is the antithesis of "engagement" which often has some time on site metric they're hunting.
If you can find what you want and read it you might not spend 5 extra seconds lost on their page and thus they can pad their stats for advertisers. Bonus points if the stupid page loads in such a way you accidentally click on something and give them a "conversion".
Sadly financial incentive is almost always towards tricking people into doing something they don't want to do instead of just actually giving them what they fucking want.
> Sadly financial incentive is almost always towards tricking people into doing something they don't want to do instead of just actually giving them what they fucking want.
Northstar should be user satisfaction. For some products that might be engagement (eg entertainment service) while for others it is accomplishing a task as quickly as possible and exiting the app.
The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text.
HN might have over 100 chars per line of text. It could be better. I know I could do it myself, and I do. But "I fixed it for me" doesn't fix it for anyone else.
I don't think it was UI that killed Slashdot. The value was always in the comments, and in the very early years often there would be highly technical SMEs commenting on stories.
The site seemed to start to go downhill when it was sold, and got into a death spiral of less informed users, poor moderation, people leaving, etc. It's amazing that it's still around.
For me, Slashdot became full of curmudgeons. It’s pretty tiring when every “+5 Insightful” on a hard drive article questioning why you’d ever want so big of a drive, or why you’d require more than 256 colors or whatever new thing came out… like why are you even on a technology enthusiast site when you bitterly complain about every new thing? Basically either accept change or get left in the dust and slashdot’s crowd seemed determined to be left in the dust… forever loosing its relevance in the tech community.
Plus Rusty just pushed out Kuro5hin and it felt like “my scene” kind of migrated over.
As an aside, Kuro5hin was the only “large” forum that I ever bothered remembering people’s usernames. Every other forum it’s all just random people. (That isn’t entirely true, but true enough)
It brings me genuine joy to use websites like HN or Rock Auto that haven't been React-ified. The lack of frustration I feel when using fast interfaces is noticeable.
I don't really get why so many websites are slow and bloated these days. There are tools like SpeedCurve which have been around for years yet hardly anyone I know uses them.
It’s not modern UIs that prevent websites from being performant. Look at old.reddit.com, for instance. It’s the worst of both worlds. An old UI that, although much better than its newer abomination, is fundamentally broken on mobile and packed to the gills with ad scripts.
What changes have been made to the HN design since it was launched?
I know there are changes to the moderation that have taken place many times, but not to the UI. It's one of the most stable sites in terms of design that I can think of.
What other sites have lasted this long without giving in to their users' whims?
Over the last 4 years my whole design ethos has transformed to "WWHND" (What Would Hacker News Do?) every time I need to make any UI changes to a project.
Slashdot looked a lot like HN with high information density. It was fast and easy to read all the comments. Then a redesign happened because of web 2.0 or "mobile-first" hype and most of the comments got hidden/collapsed by default, sorted almost randomly etc. So a new user would come there and say "wtf this is a dead conversation" or would have to click too many times to get to the full conversation. So new user would leave, and so would the old ones because the page was so hard to use. It just lost users and that was that. All because of the redesign which they never wanted to revert. Sad really because I still think it had/has the best comment moderation by far.
I routinely notice a handful of people, such as Thomas Ptacek, whose opinions I have opinions about, and then in context I notice e.g. Martin Uecker for C and especially the pointer provenance problem (on which he has been diligently working for some years), or Walter Bright (for the D language), or Steve Klabnik (Rust)
There are people who show up much less often and have less obvious usernames, Andrew Ayer is agwa for example, and I'm sure there are people I blank on entirely.
Once in a while I will read something and realise oh, that "coincidental" similarity of username probably isn't a coincidence, I believe the first time I realised it was Martin Uecker was like that for example. "Hey, this HN person who has strong opinions about the work by Uecker et al has the username... oh... Huh. I guess I should ask"
HN goes to some lengths to de-emphasize the usernames, leaving them small and medium grey against a light grey background. It's not easy to track usernames here. Some other forums put far more emphasis on them, even letting users upload icons so you can tell who is who at a glance.
Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and providers a better service).
ive approached the same thing but slightly differently. i can run it on consumer hardware for vastly cheaper than the cloud and don't have to worry about image sizes at all. (bare metal is 'faster') offering 20,000 minutes of transcription for free up to the rate limit (1 Request Every 5 Seconds)
if you ever want to chat about making transcription virtually free or so cheap for everyone let me know. I've been working on various projects related to it for a while. including open source/cross-platform superwhisper alternative https://handy.computer
> i can run it on consumer hardware for vastly cheaper than the cloud
Woah, that's really cool, CJ! I've been toying the with idea of standing up a cluster of older iPhones to run Apple's Speech framework. [1] The inspiration came from this blog post [2] where the author is using it for OCR. A couple of things are holding me back: (1) the OSS models are better according to the current benchmarks and (2) I have customers all over the world, so that geographical load-balancing is a real factor. With that said, I'll definitely spend some time checking out your work. Thanks for sharing!
Well said. And it's not just the cloud. We self-host at my job and there are real cost savings to speed here too. Being able to continue using an old server for another year and having your staff be just a little more efficient adds up quickly.
Yep. I'm hoping that installed copies of PAPER (at least on Linux) will be somewhere under 2MB total (including populating the cache with its own dependencies etc). Maybe more like 1, although I'm approaching that line faster than I'd like. Compare 10-15 for pip (and a bunch more for pipx) or 35 for uv.
Fast doesn't necessarily mean efficient/lightweight and therefore cheaper to deploy. It may just mean that you've thrown enough expensive hardware at the problem to make it fast.
Hmm… That's a good point. I recall a few instances where I went too far to the detriment of production. Having a trusty testing and benchmarking suite thankfully helped with keeping things more stable. As a solo developer, I really enjoy the development process, so while that bit is costly, I didn't really consider that until you mentioned it.
This is interesting. It got me to think. I like it when articles provoke me to think a bit more on a subject.
I have found this true for myself as well. I changed back over to Go from Rust mostly for the iteration speed benefits. I would replace "fast" with "quick", however. It isn't so much I think about raw throughput as much as "perceived speed". That is why things like input latency matter in editors, etc. If something "feels fast" (ie Go compiles), we often don't even feel the need to measure. Likewise, when things "feel slow" (ie Java startup), we just don't enjoy using them, even if in some ways they actually are fast (like Java throughput).
I feel the same way about Go vs Rust. Compilation speed matters. Also, Rust projects resemble JavaScript projects in that they pull in a million deps. Go projects tend to be much less dependency happy.
One of the Rust ecosystem's biggest mistakes, in my opinion, was not establishing a fiercely defensive mindset around dependency-bloat and compilation speed.
As much as Rust's strongest defenders like to claim, compilation speed and bloat just really wasn't a goal. That's cascaded down into most of the ecosystem's most used dependencies, and so most Rust ecosystem projects just adopt the mindset of "just use the dependency". It's quite difficult to build a substantial project without pulling in 100s of dependencies.
I went on a lengthy journey of building my own game engine tools to avoid bloat, but it's tremendously time consuming. I reinvented the Mac / Windows / Web bindings by manually extracting auto-generated bindings instead of using crates that had thousands of them, significantly cutting compile time. For things like derive macros and serialization I avoided using crates like Serde that have a massive parser library included and emit lots of code. For web bindings I sorted out simpler ways of interacting with Javascript that didn't require a heavier build step and separate build tool. That's just the tip of the iceberg I can remember off the top of my head.
In the end I had a little engine that could do 3D scenes, relatively complex games, and decent GPU driven UI across Mac, Windows, and Web that built in a fraction of the time of other Rust game engines. I used it to build a bunch of small game jam entries and some web demos. A clean release build on the engine on my older laptop was about 3-4 seconds, vastly faster than most Rust projects.
The problem is that it was just a losing battle. If I wanted Linux support or to use pretty much any other crate in the Rust ecosystem, I'd have to pull in dependencies that alone would multiple the compile time.
In some ways that's an OK tradeoff for an ecosystem to make, but compile times do impede iteration loops and they do tend to reflect complexity. The more stuff you're building on top of the greater the chances are that bugs are hard to pin down, that maintainers will burn out and move on, or that you can't reasonably understand your stack deeply.
Looking completely past the languages themselves I think Zig may accrue advantages simply because its initial author so zealously defined a culture that cares about driving down compile times, and in turn complexity. Pardon the rant!
And that leads to dependency hell once you realize that those dependencies all need different versions of the same crate. Most of the time this "just works" (at the cost of more dependencies, longer compile time, bigger binary)... until it doesn't then it can be tough to figure out.
In general, I like cargo a lot better than the Go tooling, but I do wish the Rust stdlib was a bit more "batteries included".
This is all well and good that we developers have opinions on whether Go compiles faster than Rust or whatever, but the real question is: which is faster for your users?
...and that sounds nice to me as well, but if I never get far enough to give it to my users then what good is fast binaries? (implying that I quit, not that Rust can't deliver). The holy grail would be to have both. Go is generally 'fast enough', but I wish the language was a bit more expressive.
I've noticed over and over again at various jobs that people underestimate the benefit of speed, because they imagine doing the same workflow faster rather than doing a different workflow.
For example, if you're running experiments in one big batch overnight, making that faster doesn't seem very helpful. But with a big enough improvement, you can now run several batches of experiments during the day, which is much more productive.
I think people also vastly underestimate the cost of context switching. They look at a command that takes 30 seconds and say "what's the point of making it take 3 seconds? you only run it 10 times in a day; it's only 5 minutes". But the cost is definitely way more than that.
Telegram is pretty slow, both the web interface and the Android app. For example, reactions to a message always take a long time to load (both when leaving one, and when looking at one). Just give me emoji, I don't need your animated emoji!
Website is superfast. Reason I usually go for the comments first on HN is exactly this: they're fast. THIS is notably different.
On interfaces:
It's not only the slowness of the software or machine we have to wait for, it's also the act of moving your limb that adds a delay. Navigating a button (mouse) adds more friction than having a shortcut (keyboard). It's a needless feedback loop. If you master your tool all menus should go away. People who live in the terminal know this.
As a personal anecdote, I use custom rofi menus (think raycast for Linux) extensively for all kinds of interaction with data or file system (starting scripts, opening notes, renaming/moving files). It's notable how your interaction changes if you remove friction.
Venerable tools in this vein: vim, i3, kitty (former tmux), ranger (on the brim), qutebrowser, visidata, nsxiv, sioyek, mpv...
Essence of these tools is always this: move fast, select fast and efficiently, ability to launch your tool/script/function seamlessly. Be able to do it blindly. Prefer peripheral feedback.
I wish more people saw what could be and built more bicycles for the mind.
The website is fast because it's minimal, just under 80 kB of which 55 is the custom font; this is fine for plain content sites, but others will have other requirements.
There's never a reason to make a content website use heavyweight JS or CSS though.
> Rarely in software does anyone ask for “fast.” We ask for features, we ask for volume discounts, we ask for the next data integration. We never think to ask for fast.
Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company.
At companies that had us target metrics, speed and latency was always a metric.
I don’t think my experience has been all that unique. In fact, I’d be more surprised if I joined a company and they didn’t care about how responsive the product felt, how fast the pages loaded, and any weird lags that popped up.
At 6 out of 8 companies I've worked at (mostly a mixture of tech & finance) I have always had to fight to get any time allotted for performance optimization, to the point where I would usually just do it myself under the radar. Even at companies that measured latency and claimed it was important, it would usually take a backseat to adding more features.
My experience has been that people sometimes obsess over speed for things like how fast a search result returns but not over things like how fast a page renders or how many bites we send the user.
I find most jobs I had fast becomes a big issue once things are too slow. Or expensive.
It's a retroactively fixed thing. Like imagine forgetting to make a UI, shipping just an API to a customer then thinking "oh shit, they need a UI they are not programmers". And only noticing from customer complaints. That is how performance is often treated.
This is probably because performance problems usually require load or unusual traffic patterns, which require sales, which require demos, which dont require performance tuning as there is one user!
If you want to speed your web service up first thing is invest time, maybe money in really good observability. Should be easy for anyone in the team to find a log, see what CPU is at etc. Then set up proxy metrics around speed you care about and talk about them every week and take actions.
Proxy metrics means you likely cant (well probably should not) check the speed that Harold can sum his spreadsheet every minute, but you can check the latency of the major calls involved. If something is slow but metrics look good then profiling might be needed.
Sometimes there is an easy speed up. Sometimes you need a new architecture! But at least you know what's happening.
In addition to all this, I’m also of the opinion that most users just have software “lumped on them” and have little to no recourse for complaint, so they’re just forced/trained to put-up-and-shut-up about it.
As a result, performance (and a few other things) functionally never gets “requested”. Throw in the fact that for many mid-to-large orgs, software is not bought by the people who are forced to use it and you have the perfect storm for never hearing about performance complaints.
This in turn, justifies never prioritising performance.
No mention of google search itself being fast. It's one of the poster children of speed being part of the interface.
Microsoft needs to take heed, for example Explorer's search, Teams, make your computer seem extremely slow. VS Code on the other hand is fast enough, while slower than native editors such as Sublime Text.
Well, that depends. Very inefficient code tends to only be used when absolutely needed. If an LLM becomes ten times faster at answering simple prompts, it may very well be used a hundred times more as a result, in which case electricity use will go up, not down. Efficiency gains commonly result in doing way more with more, not more with less.
Energy used for lighting didn't decrease when the world moved to LED lights which use much less energy - instead we just used more lighting everywhere, and now cities are white instead of yellow.
Very true, but in recent years feature development has taken precedence over efficiency. VP of whatever says hardware is cheap, software engineers are not.
The industry (hint:this forum's readers) have replaced "fast" software with "portable" meaning
-universally addressable libraries that must load from discrete and often remote sources,
-zero hang time in programming language evolution (leaving no time for experts to discover, document, and implement optimizations)
-insistence on "the latest version" focused software with no emphasis on long term code stability
Only sorta related, but it’s crazy that to me how much our standards have dropped for speed/responsiveness in some areas.
I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game.
Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable.
> I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable
Your experience is not normal.
If you’re seeing that much lag, the most likely explanation is your display. Many TVs have high latency for various processing steps that doesn’t matter when you’re watching a movie or TV, but becomes painful when you’re playing games.
This does not undermine chamomeal's argument. The whole point is that back in the N64 days, they could not possibly have had that experience. There was no way to even make it happen. The fact that today it's a real possibility when you've done nothing obviously wrong is a definite failure.
it's possible, but it seems to specifically be a rocket league on xbox series s problem, not a display problem. Other games run totally fine on the same display with no lag!
That may be an issue of going from a CRT tv to an LCD tv. As far as I am aware there was no software manipulation of the video input on a CRT. It just took the input and displayed it on the screen in the only way it could. Newer tvs have all kinds of settings to alter the video which takes processing time. They also typically have a game mode to turn off as much of it as it will allow.
Why should the user care whether the lag is introduced by the software in the controller, or the software in the gaming console, or the software in the tv.
The lag is due to some software. So the problem is with how software engineering as a field functions.
I hear it claimed that you're only supposed to enable game mode for competitive multiplayer games -- but I've found that many single player games like Sword Art Online: Fatal Bullet are unplayable without game mode enabled.
It could be my unusual nervous system. I'm really good at rhythm games, often clearing a level on my first try and amazing friends who can beat me at other genres. But when I was playing League of Legends, which isn't very twitchy, it seemed like I would just get hit and there was nothing I could do about it when I played on a "gaming" laptop but found I could succeed at the game when I hooked up an external monitor. I ran a clock and took pictures showing that the external monitor was 30ms faster than the built-in monitor.
How about the speed of going from a powered off console to playing the actual game? Sleep mode helps with resuming on console, but god forbid you’re on a pc with a game that has anti cheat, or comped menus. You will sit there, sometimes for a full minute waiting. I absolutely cannot stand these games.
My buddy booted up his PC after gaming on his PS5 for two weeks and every single app needed multi-gig updates. Xbox app, Logitech app, Discord, Windows 11, Chrome, Steam. The whole enchilada. Rage inducing compared to sticking a cart in an N64.
Or how channel surfing now requires a 1-2 second latency per channel, versus the way it was seemingly instant from the invention of television through the early 1990s.
Having a lot more channels is cool I guess, but it was much better to watch and listen to a staticy analog channel 20 years ago, than a digital channel today where there is no audio and the image freezes.
Heck yes! I recently dusted off (had to literally dust the inside of the cartridges to get past a black screen, lol) my old Sega Genesis (and bought an HDMI adaptor for it), and have been letting my school age sons play it. They haven't even commented on the basic graphics. They're like "wow dad, no boot time, no connecting to server time, no waiting to skip ads time". They love it.
I was going to say one of the more recent times fast software excited me was with `uv` for Python packaging, and then I saw that op had a link to Charlie Marsh in the footnote. :)
I once accidentally blocked TCP on my laptop and found out "google.com" runs on UDP, it was a nice surprise.
baba is fast.
I sometimes get calls like "You used to manage a server 6 years ago and we have an issue now" so I always tell the other person "type 'alias' and read me the output", this is how I can tell if this is really a server I used to work on.
They don't require you to use QUIC to access Google, but it is one of the options. If you use a non-supporting browser (Safari prior to 2023, unless you enabled it), you'd access it with a standard TCP-based HTTP connection.
> this is how I can tell if this is really a server I used to work on
Hm, shell environment is fairly high on the list of things I'd expect the next person to change, even assuming no operational or functional changes to a server.
And of course they'd be using a different user account anyway.
For what is worth I built myself a custom jira board last month, so I could instantly search, filter and group tickets (by title, status, assignee, version, ...)
Motivation: Running queries and finding tickets on JIRA kills me sometimes.
The board is not perfect, but works fast and I made it superlightweight. In case anybody wants to give it a try:
Don't dare to try on mobile, use desktop. Unfortunately it uses a proxy and requires an API key, but doesn't store anything in backend (just proxies the request because of CORS). Maybe there is an API or a way to query jira cloud instance directly from browser, I just tried first approach and moved on. It even crossed my mind to add it somehow to Jira marketplace...
Anyway, caches stuff locally and refreshes often. Filtering uses several tricks to feel instant.
UI can be improved, but uses a minimalistic interface on purpose, like HN.
If anybody tries it, I'll be glad to hear your thoughts.
make fast sexy again... please
growing up I've thoroughly enjoyed seeing workers tapping away at registers where it doesn't have a mouse, all muscle memory and layers and layers of menu accessible by key taps, whether it's airline, clothing store, even some restaurant used to have those dimly lit terminals glowing green or orange with just bunch of text and a well versed operator chatting while getting their work done. the keys were commercial grade mechanical which made pleasing sound.
nowadays it's fancy touch display, requires concentration and often sluggish, and the machine often felt cheap and made cheap sound when tapped on, I don't think the operator are ever enjoying interacting with it and the software's often slow across the network....
I'm all for fast. It shows no matter what, at least somebody cared enough for it to be blazing fast.
> Developers ship more often when code deploys in seconds (or milliseconds) instead of minutes.
I don't want my code deployed in seconds or milliseconds. I'm happy to wait even an hour for my deployment to happen, as long as I don't have to babysit it.
I want my code deployed safely, rolled out with some kind of sane plan (like staging -> canary -> 5% -> 20% -> 50% -> 100%), ideally waiting long enough at each stage of the plan to ensure the code is likely being executed with enough time for alerts to fire (even with feature flags, I want to make sure there's no weird side effects), and for a rollback to automatically occur if anything went wrong.
I then want to enable the feature I'm deploying via a feature flag, with a plan that looks similar to the deployment. I want the enablement of the feature flag, to the configured target, to be as fast as possible.
I want rollbacks to be fast, in-case things go wrong.
Another good example is UI interactions. Adding short animations to actions makes the UI slower, but can considerably improve the experience, by making it more obvious that the action occurred and what it did.
So, no, fast isn't always better. Fast is better when the experience is directly improved by making it fast, and you should be able to back that up with data.
This is one of the reasons I switched from Unity to Godot. There is something about Godot loading fast and compiling fast that makes it so much more immersive to spend hours chugging away at your projects for.
There might be some selection bias - Experienced programmers who care a lot about engine technology are more likely to use Godot and also optimize their load times. Unity includes a lot of first-time programmers who just want to get something shipped
I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.
"Community banks mostly don’t have programmers on staff, and are reliant on the so-called “core processors” ...
This is the largest reason why in-place upgrades to the U.S. financial system are slow. Coordinating the Faster ACH rollout took years, and the community bank lobby was loudly in favor of delaying it, to avoid disadvantaging themselves competitively versus banks with more capability to write software (and otherwise adapt operationally to the challenges same-day ACH posed)."
For ACH, it's the scheduling and batching that makes it slow. The transfer itself should be instant but often my bank sends it out around midnight. This is why Venmo and Zelle are so popular. You can also modify/cancel a bank transfer before it goes through, which is nice.
This is the same in Switzerland. If you request an IBAN transfer, it's never instant. The solution there for fast payments is called TWINT, which works at almost POS terminal (you take a picture of the displayed QR code).
I think BACS is similarly "slow" due to the settlement process.
These days ACH settlement runs multiple times a day. The biggest source of delay for ACH transfers is your bank delaying release of the funds for risk management. ACH transfers can be reversed even after they have "settled" and if the receiving bank has already disbursed the funds then they have to eat the cost of reimbursing the sender. Reversals are more likely to happen soon after the transfer completes, so delaying release of the funds makes it less likely the bank will be left holding the bag.
Prior to that, you could get instant transfers but it came with a small fee because they were routed through credit card networks. The credit card networks took a fee but credit card transactions also have different guarantees and reversibility (e.g. costing the bank more in cases of fraud)
I am convinced that this is in some cases a pro-consumer behavior. A credit card company once pulled money from my bank via ACH due to the automatic payment feature I set up, but that bank account didn't have enough money in it. The bank sent me at least two emails about the situation. I finally noticed that second email and wired myself more money from a different account. The credit card company didn't notice anything wrong and didn't charge any late fees or payment returned fees. The bank didn't charge any overdraft fees or insufficient funds fees. And the wire transfer didn't have a fee due to account balance. (Needless to say, from then on I no longer juggle multiple bank accounts like that.)
The bank had an opportunity to notify me precisely because ACH is not real time. And I had an opportunity to fix it because wire transfers is almost real time (finishes in minutes not days). I appreciate it when companies pull money from my account I get days of notice but if I need to move money quickly I can do it too.
In most cases it's definitely better for it to be fast. For example I sold a buggy face to face today and they paid me by bank transfer, and the reason we could do that was that I had a high confidence it would turn up quickly and they weren't trying to scam me. It actually took around 1 second which is really quite fast.
You don't need slow transfers to get an opportunity to satisfy automatic payments. I don't know how it works but in the UK direct debits (an automatic "take money from my account for bills" system) gives the bank a couple of days notice so my banking app warns me if I don't have enough money. Bank transfers are still instant.
We're pretty lucky here in Australia. Over the past decade or so, PayID has been successfully rolled out to virtually all banks, giving us free and (usually) instant money transfers - I'd say more than half of all personal payments are now done with PayID. Old-skool bank transfers are still the norm for business and administrative payments, but that's changing too, and in any case, those transfers are increasingly being executed behind the scenes over Osko (aka PayID), so they end up settling in seconds (or at least hours) instead of days.
IS IT NOW!? last time I visited (long time ago) it was BACS, and the bank clerk told me it takes one day to "properly" register they've received my fund, one day to make sure it transferred and on the third and final day, the other bank can "properly" acknowledge they've received the fund thus why it took 3 FRIGGIN DAYS. I used so much cash back then.
I think that people generally underestimate what even small increases in the interaction time between human and machine cost. Interacting with sluggish software is exhausting, clicking a button and being left uncertain whether it did anything is tedious and software being fast is something you can feel.
Windows is the worst offender here, the entire desktop is sluggish even though it there is no computational task which justifies those delays.
Apple software, especially lately, can be really bad for it too. Single core perf is slightly better on my iPad than my MacBook Pro and yet everything feels an order of magnitude slower. If I am impatiently tapping the space I know a button will appear waiting for an animation to finish, some aspect of software design has gone horribly awry.
C++ with no forward decls, no clang to give data about why the compile time is taking so long. 20 minute compiles. Only git tool I like (git-cola) is written in Python and slows to a crawl. gitk takes a good minute just to start up. Only environments are MSYS which is slow due to Windows, and WSL which isn't slow but can't do DPI scaling so I squint at everything.
I might get down voted for saying this on HN, but I'll still say it.
As C++ devs we used to complain a lot about it's compilation speed. Now after moving to Rust, sometimes we wish we could just go back to C++ due to Rust's terrible compilation speeds! :-)
I don't think I can relate this article to what actually happened to the web. It went from being an unusable 3D platform to a usable 2D one. The web exploded with creativity and was out of control thanks to Flash and Director, but speeds were unacceptable. Once Apple stopped supporting it, the web became boring, and fast, very fast. A lot of time and money went into optimising the platform.
So the article is probably more about LLMs being the new Flash. I know that sounds like blasphemy, but they're both slow and melt CPUs.
The web might be fast compared to in 2005 but only if you don't normalize for average CPU performance and bandwidth. Websites that are mostly text often still manage to take remarkable amounts of time to finish rendering and stop moving things around.
I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other.
My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.
Software that goes fast changes human behavior. It seems you’re thinking it changes the software’s behavior. Not sure. Either that, or I don’t follow your comment at all.
I'm not really sure how to rephrase it, so I can try an example.
Lets say that the author has a machine that is a self contained assembly line, it produces cans of soup. However, the machine has a problem - every few cans of soup, one can comes out sideways and breaks the machine temporarily, making them stop and unjam it.
The author suggests to double the speed of the machine without solving that problem, giving them their soup cans twice as fast, requiring that they unjam it twice as often as well.
I believe that (with situation exceptions) this is a bad approach, and I would address the problem causing the machine to get jammed before I doubled the speed of the machine
That being said, this is a very simplistic view of the situation, in a real situation either of these solutions has a number of variables that may make it preferable over the other - my gripe with the piece is that the author suggests the "faster" approach is a good default that is "simple", "magical" and "fun". I believe it is shortsighted, causes compounding problems the more it is applied in sequence, and is only "magical" if you bury your head in the sand and tell yourself the problems are for someone else to figure out - which is exactly what the author handwaves away at the end, with a nebulous allusion to some future date when these tools that we should accept because they are fast will eventually be made good by some unknown person.
More like 300x if you count working hours. Although I've yet to see anything that would take a person a few days (assuming the task is worth spending a few dats on) and that an LLM could do in six minutes, even with human assistance.
Very much the opposite in my experience. People, especially on this site, ask for "fast" regardless of whether they need it. If asked "how fast?" the answer is always "as fast as possible". And they make extremely poor choices as a result. Fast is useful up to a point, but faster than that is useless - maybe actively detrimental if you can e.g. generate research reports faster than you can read them.
You make much better code, and much better products, if you "fast" from your vocabulary. Instead set specific, concrete latency budgets (e.g. 99.99% within x ms). You'll definitely end up with fewer errors and better maintainability than the people who tried to be "fast". You'll often end up faster than them too.
I’m senior developer on a feature bloated civil engineering web app that has 2 back end servers (one just proxies to the other) and has 8k lines of stored procedures as the data layer and many multi k line react components that intentionally break react best practices.
I loathe working on it but don’t have the time to refactor legacy code.
———————-
I have another project that I am principal engineer and it uses Django, nextjs, docker compose for dev and ansible to deploy and it’s a dream to build in and push features to prod. Maybe I’m more invested so it’s more interesting to me but also not waiting 10 seconds to register and hot reload a react change is much more enjoyable.
If it’s something simple, I’ll use Django template because it’s very easy. Most stuff I work on these days requires more fancy ui so I’ll 100% use react or nextjs for front end (and I’ve be using zustand for state management). I’ll have an api util that uses axios and handles appending a jwt auth header to all requests and use that in my components. I like using Django-all-auth because it makes integrating email/google/microsoft auth really easy out of the box.
DRF is good, ninja is a little more light weight and flexible so it really comes down to the project.
> it's obvious to anyone that writes code that we're very far from the standards that we're used to
This is true, but I also think there's a backlash now and therefore some really nice mostly dev-focused software that is reeaaaaly fast. Just to name a few:
That's a tiny subsection of the mostly bloated software that exists. But it makes me happy when I come across something like that!
Also, browsers seems to be really responsive despite being one of the most feature bloated products on earth thanks to expanding web standards. I'm not really counting this though because Firefox and Chrone might rarely lag, the websites I view with them often do, so it's not really a fast experience.
I don't know, there are a sizeable subset of folks who value fast, and it's a big subset, it's not niche.
Search for topics like turning off animations or replacing core user space tools with various go and rust replacements, you'll find us easily enough.
I'm generally a pretty happy MacOS user, especially since M1 came along. But I am seriously considering going back to linux again. I maintain a parallel laptop with nixos and i'm finding more and more niggles on the mac side where i can prioritise lower friction on linux.
According to Wikiquotes, this is a common misattribution, and the first known record is Ruth M. Davis from 1978, who attributes it to Lenin: https://en.wikiquote.org/wiki/Quantity
I feel like this should have some kind of "promotional" or "ad" label. I agree wholeheartedly with the words here, but I also note that the author is selling the fast developer tools she laments the dearth of: https://www.catherinejue.com/kernel
Again, no ill will intended at all, but I think it straddles the promotional angle here a bit and maybe people weren't aware
The tool in question is also a fairly unethical scraping and botting tool, advertising defrauding services to bypass captchas and scrape websites against the owners' wishes.
One of the biggest things our framework does as opposed to React, Angular, Vue etc. is we lazyload all components as you need them. No need for tree-shaking or bundling files. Just render (static, cached) HTML and CSS, then start to activate JS on top of it. Also helps massively with time to first contentful paint.
> Superhuman's sub-100ms rule—plus their focus on keyboard shortcuts—changed the email game in a way that no one's been able to replicate, let alone beat.
I often hear this sort of thing "Facebook was a success using PHP therefore language choice isn't important" or in this case "superhuman made their product fast and they still failed so speed isn't important".
It's obviously wrong if you think about it for more than a second. All it shows is that speed isn't the only thing that matters but who was claiming that?
Speed is important. Being slow doesn't guarantee failure. Being fast doesn't guarantee success. It definitely helps though!
Also sometimes speedyness or responsiveness beyond nominal is not as much of a "must have" compared to nominally fast performance in place of sluggishness.
As some working on embedded audio DSP code I just had to laugh a little.
Yes, there is a ton of code that has a strict deadline. For audio that may be determined by your buffer size — don't write your samples to that buffer fast enough and you will hear it in potentially destructively loud fashion.
This changes the equation, since faster code now just means you are able to do more within that timeframe on the same hardware. Or you could do the same on cheaper hardware. Either way, it matters.
Similar things apply to shader coding, game engines, control code for electromechanical systems (there, missing the deadline can be even worse).
> When was the last time you used airplane WiFi and actually got a lot done?
The greatest day of productivity in my life was a flight from Melbourne to New York via LAX. No wifi on either flight, but a bit in transit. Downloaded everything I needed in advance. Coded like a mofo for like 16 hours.
Back in the 90's I ran a dev team building Windows applications in VB, and had the rule that the dev machines had to be lower-specced than the user machines they were programming for.
It was unpopular, because devs love the shiny. But it worked - we had nice quick applications. Which was really important for user acceptance.
I didn't make this rule because I hated devs (though self-hatred is a thing ofc), or didn't want to spend the money on shiny dev machines. I made it because if a process worked acceptably quickly on a dev machine then it never got faster than that. If the users complained that a process was slow, but it worked fine on the dev's machine, then it proved almost impossible to get that process faster. But if the dev experience of a process when first coding it up was slow, then we'd work at making it faster while building it.
I often think of this rule when staring at some web app that's taking 5 minutes to do something that appears to be quite simple. Like maybe we should have dev servers that are deliberately throttled back, or introduce random delays into the network for dev machines, or whatever. Yes, it'll be annoying for devs, but the product will actually work.
> Like maybe we should have dev servers that are deliberately throttled back
This is a good point. Often datasets are smaller in dev. If a reasonable copy of live data is used, devs would have an intuition of what is making things slow. Doesn't work for live data that is too big to replicate on a developer's setup though.
I work on optimization a large fraction of my time. It is not something learned in a week, month or even a year.
At least in B2B applications that rely heavily on relational data, the best developers are the ones who can optimize at the database level. Algorithmic complexity pretty much screams at me these days and is quickly addressed, but getting the damned query plan into the correct shape for a variety of queries remains a challenge.
Of course, knowing the correct storage medium to use in this space is just as important as writing good queries.
Superhuman achieved their sub-something speed maybe (has anyone measured it except them? Genuinely, post a link, appreciated)
However the capital required will probably never happen again in relation to the return for any investor involved in that product.
Props to them for pushing the envelope, but they did it in the zero interest era and its a shame this is never highlighted by them. And now the outcome is pretty clear in terms of where the company has ended up.
The flip-side of this is that if something is too fast, it raises doubts about whether it actually happened at all. I'm reminded of the TurboTax case, where Intuit found that adding a bunch of artificial loading screens to make it look like TurboTax was taking its time to really pore over customers' tax returns ended up being more appealing to users than not doing so. The actual "analyses" happen within less than a second, but that was (allegedly) too fast for users to believe.
A ticket booking system I was familiar with added latency after upgrades to maintain a particular experience for the operators.
I guess they were used to typing stuff then inspecting paperwork or other stuff waiting for a response. Plus, it avoided complaints when usage inevitably increased over time.
That’s an unusual case because most customers use it once a year, and speed is number 3 or 4 on their priorities behind getting it right (not getting in trouble), and understanding wtf is going on.
What's amazing to me is that often all it takes to go fast is to keep things simple. JBlow once said that software should be treated like a rocket ship: every thing you add contributes weight.
Linus Torvalds said exactly that in a talk about git years ago. It's crazy to think back how people used to use version control before git. Git totally changed how you can work by being fast.
Interesting that onkernel.com intentionally animates and slows down the loading of the web interface, making it harder to scroll and scan the site. Irony or good design?
The article makes two points—one about software performance, the other about development performance. On the topic of software performance, I think the best explanation I got came from the great Prof. Charles Leiserson’s MIT course on performance engineering: performance is a currency. It’s something we spend to gain other qualities—safety, rich features, user-friendliness, and so on. At the end of the day, a computer can executes about 100 simple primitve instructions. The reason we have a software industry is because of speed.
My favourite example of not "fast" right now is any kind of Salesforce report. Not only are they slow but you can't make any changes to the criteria more often than once a minute. Massively changes your behaviour.
Adding to this - that's why I insist all my students should learn touch-typing, for at least 10 minutes per lesson. It really changes how you interact with your computer, and how much touch typing quickly makes you able to type as fast as you can think changes your approach to automating things in a quick script or doing some bash-fu. A very underrated skill in todays world.
I agree, but I wonder how not knowing how to spell would affect that. The highschool kids I work with, are not great spellers (nor do they have good handwriting).
Speed is an important usability consideration that gets disproportionate focus among many developers because it’s one of the few they can directly address with their standard professional toolkit. I think it’s a combo of a Hammer/Nail thing, and developers loving the challenge of code performance golf. (Though I never loved stuff like that, which is in part why I’m not a developer anymore.)
Figuring out the best way to present logically complex content, controls and state to users that don’t wrangle complexity for a living is difficult and specialized work, and for most users, it’s much more important than snappy click response.
Both of these things obviously exist on a spectrum and are certainly not mutually exclusive. (ILY McMaster-Carr) But projects rarely have enough time for either complete working features, or great thoughtful usability, and if you’re weighing the relative importance of these two factors, consider your audience, their goals, and their technical savvy before assuming good performance can make up for a suboptimal user workflow.
That's because it's understood that things should work as quickly as possible, and not slowly on purpose (generally). No one asks that modern language is used in the UI as opposed to Sanskrit or heiroglyphs, because it's understood.
It is implicit, in the same way that in a modern car you expect electric windows and air-conditioning (yes, back in the day, those were premium extras)
I once used Notion at work and for personal note taking. I'd never felt it was "slow." Until later I moved my notes to Obsidian. Now when I have to use Notion at my job it feels sluggish.
Obsidian's local first editing experience makes a huge difference to creativity and flow.
I've been working on making Obsidian real-time collaborative with the Relay [0] plugin. In combination with a few other plugins (and the core Bases plugin) you can build a pretty great Notion alternative.
I'm bullish on companies using Obsidian for knowledge management and AI driven workflows. It's pretty reasonable to build custom plugins for a specific vertical.
This is a great blog post. I have seen internal studies at software companies that demonstrate this, i.e. reducing UI latency encourages more software use by users. (Though a quick search suggests none are published.)
This page (consisting of 693 words) took a full second to load for me because it had to import multiple fonts from Google (which also constitute over 70% of the page's size).
Yep. I often choose LLM apps not because of how great the model is, but how snappy the UI feels. Similarly I might choose the more lightweight models because they’re faster.
Conversely, we have a whole generation of entry-level developers who think 250ms is "fast," when doing on-device processing work on computers that have dozens of cores.
Fun conveys opportunity and emotion: "changing behavior", "signals simplicity", "fun". Fun creates an experience, a mode, and stickiness. It's good for marketing, but a drag on operations.
Fast is principles with methods that just work. "Got it."
Fast has a time-to-value of now.
Fast is transformative when it changes a background process requiring all the infrastructure of tracking contingencies to something that can just be done. It changes system-2 labor into system-1 activity -- like text reply vs email folders, authority vs discussion, or take-out vs. cooking.
When writers figure out how to monetize fast - how to get recurrent paying users (with out-of-band payment) just from delivering value - then we'll no longer be dragged through anecdotes and hand-waving and all the salience-stretching manipulations that tax our attention.
Imagine an AI paid by time to absorb and accept the answer instead of by the token.
Fast is better than fun -- assuming it's all good, of course :)
> Instant settle felt surprising in a world where bank transfers usually take days.
Yeah, that's not "a world" it's just the USA. Parts of the world - EU, UK etc have already moved on from that. Don't assume that the USA is leading edge in all things.
"In a world" is a figure of speech which acknowledges the non-universality of the statement being made. And no it is not "just the USA". Canada and Mexico are similarly slow to adopt real-time payments.
It is wild to tell someone "don't assume" when your entire comment relies on your own incorrect assumption about what someone meant.
There is better commentary on the same basic point regarding SEPA / Faster Payments / FedNow and how the US lags world-leading practice in the other thread here: https://news.ycombinator.com/item?id=44738579
It's a bit more substantial, and less complaints about the semantics of the wording.
Is it just me or is the premise of this the opposite of your work life as well? I have worked in the space of "fast" primarily and that is the main objective. Fast, iterate ... Don't be like "IT" (the slow team nobody can fire who never finishes anything).
Of course fast has downsides but it's interesting this pitch is here. Must have occurred many times in the past.
"Fast" was often labeled "tactical" (as opposed to "strategic" in institutions). At the time I remember thinking a lot about how delays plus uncertainty meant death (nothing gets done, or worse). Even though Fast is often at the cost of noise and error, there is some principle that it can still improve things if not "too far".
This is such an important principle to me that I've spent a lot of effort developing tooling and mental models to help with. Biggest catalyst? Being on-call and being woken up at 3am when you're still waking up... in that state, you really( don't want things to go slowly. You just want to fix the damn thing and get back to sleep.
For example, looking up command flags within man pages is slooooow and becomes agonizingly frustrating when you're waking up and people are waiting for you so that they can also go back to sleep. But if you've spent the time to learn those flags beforehand, you'll be able to get back to sleep sooner.
One of these days I’m going to get around to writing a little bash script or something that will let me take a plain-ish text file and upload it into Jira via the API.
I should be able to create a Jira ticket in however long it takes me to type the acceptance criteria plus a second or two. Instead I’ve got slow loading pages, I’ve got spinners, I’ve got dropdowns populating asynchronously that steal focus from what I’m typing, I’ve got whatever I was typing then triggering god knows what shortcuts causing untold chaos.
For a system that is—at least how we use it at my job—a glorified todo list, it is infuriating. If I’m even remotely busy lately I just add “raise a ticket for x” to my actual todo list and do it some other time instead.
That article loses its credibility because of this, my thoughts too. Facebook and Instagram websites are among the worse offenders when it comes to "time-to-content" or whatever metric cool kids use these days. Maybe the apps are faster, but I'd rather avoid spyware on my pocket computers. Probably the author is running a $3k+ laptop and renews it every year?
Oh yeah, back in the late 80s we (for some finite and not so big values of "we") were counting MOS6502/6510 cycles to catch the electron beam on a display and turn on some nice/nasty viaual effects.
But the future is vibe coding and shipping fast even if we don’t understand the code the LLM wrote!! The only speed metric worth caring about is time to market! Just fucking ship! /s
I remember the time they were cracking down because I had entered 90%+ of the tickets into the ticket system (the product manager didn't write tickets) and told me that "every ticket has to explain why it is good for the end user".
I put it in a ticket to speed up the 40 minutes build and was asked "How does this benefit the end user?" and I said "The end user would have had the product six months ago if the build was faster."
I think you misunderstood the use of "fast" in the article? They mean that the software should run fast, not be produced fast necessarily. In my experience software that truly runs fast is usually much higher quality.
Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes.
I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 minutes to do what would have taken a day", but then I thought, "maybe it was 20 minutes for 4 hours worth of work". The next day I looked at it and found the logic was convoluted, it tried to write good error handling but didn't succeed. I went back and forth and ultimately wound up recoding a lot of stuff manually. In 5 hours I had it done for real, certainly with a better test suite than I would have written on my own and probably better error handling.
See https://www.reddit.com/r/programming/comments/1lxh8ip/study_...
As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my pocket, then do a code review some time later. This process is very low mental overhead for me, so it's a big productivity win.
Sounds like a slot machine. Insert api tokens, get something that's pretty close to right, insert more tokens and hope it works this time.
10 replies →
The cost is in the context switching. Throw 3 tasks that came 15, 20 and 30 min later. The first is mostly ok, you finish by hand. The second have some problems, ask for a rework. Then came the other and, while ok, is have some design problems. Ask another rework. Comes back the second one, and you have to remember the original task and what things you asked for change.
Thats cool, how are you integrating your phone with your Claude workflow?
8 replies →
I've already written about this several times here. I think the current trend of LLMs chasing benchmark scores are going in the wrong direction at least as programming tools. In my experience they get it wrong with enough probability, so I always need to check the work. So I end up in a back and forth with the LLM and because of the slow responses it becomes a really painful process and I could often have done the task faster if I sat down and thought about it. What I want is an agent that responds immediately (and I mean in subseconds) even if some benchmark score is 60% instead of 80%.
Programmers (and I'm including myself here) often go to great lengths to not think, to the point of working (with or without a coding assistant) for hours in the hope of avoiding one hour of thinking. What's the saying? "An hour of debugging/programming can save you minutes of thinking," or something like that. In the end, we usually find that we need to do the thinking after all.
I think coding assistants would end up being more helpful if, instead of trying to do what they're asked, they would come back with questions that help us (or force us) to think. I wonder if a context prompt that says, "when I ask you to do something, assume I haven't thought the problem through, and before doing anything, ask me leading questions," would help.
I think Leslie Lamport once said that the biggest resistance to using TLA+ - a language that helps you, and forces you to think - is because that's the last thing programmers want to do.
23 replies →
World of LLMs or not, development should always strive for being fast. In the LLM World, users should always have the controls on accuracy Vs speed. (Though we can try for improving both and not one way or other). For eg at rtrvr.ai we use Gemini Flash as our default and did benchmarking on flash too with 0.9 min per task in the benchmark still yielding top results. That said, I have to accept there are certain web tasks on tail end sites that needs pro to accurately navigate at this point. This is the limitation given our reliance on Gemini models straight up, once we move to our models trained on web trajectories this hopefully will not be a problem.
If using off the shelf LLMs always have a bottleneck of their speed.
GitHub copilot's inline completions still exist, and are nearly instant!
The only thing I've found that LLM speeds up my work is a sort of advanced find replace.
A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever"
It has been pretty decent at these types of changes and saves time of poking though and finding all the places I would have updated manually in a way that find/replace never could. Though I've never tried this on a huge code base.
> A prompt like " I want to make this change in the code where any logic deals with XXX. To be/do XXX instead/additionally/somelogicchange/whatever"
If I reached a point where I would find this helpful, I would take this as a sign that I have structured the code wrongly.
4 replies →
I supposed you haven’t tried emacs grep mode or vim quickfix? If the change is mechanical, you create a macro and be done in seconds. If it’s not, you still got the high level overview and quick navigation.
9 replies →
I guess it depends? The "refactor" stuff, if your IDE or language server can handle it, then yeah I find the LLM slower for sure. But there are other cases than an LLM helps a lot.
I was writing some URL canonicalization logic yesterday. Because we rolled this out as an MVP, customers put URLs in all sorts of ways and we stored it into the DB. My initial pass at the logic failed on some cases. Luckily URL canonicalization is pretty trivially testable. So I took the most used customers from our DB, send them to Claude and told Claude to come up with the "minimum spanning test cases" that cover this behavior. This took maybe 5-10 sec. I then told Zed's agent mode using Opus to make me a test file and use these test cases to call my function. I audited the test cases and ended up removing some silly ones. I iterated on my logic and that was that. Definitely faster than having to do this myself.
All the references to LLMs in the article seemed out-of-place like poorly done product placement.
LLMs are the anti-thesis of fast. In fact, being slow is a perceived virtue with LLM output. Some sites like Google and Quora (until recently) simulate the slow typed output effect for their pre-cached LLM answers, just for credibility.
I'm consistently seeing personal and shared anecdotes of a 40%-60% speedup on targeted senior work.
As much as I like agents, I am not convinced the human using them can sit back and get lazy quite yet!
Eeeh, I spend less time writing code, but way more time reviewing and correcting it. I'm not sure I come ahead overall, but it does make development less boilerplaty and more high level, which leads to code that otherwise wouldn't have been written.
2 replies →
That sounds plausible if the senior did lots of simple coding tasks and moves that work to an agent. Then the senior basically has to be a team lead and do code reviews/qa.
Curious, what do you count as senior work?
1 reply →
I switch to vs code from cursor many times a day just to use their python refactoring feature. The pylance server that comes with cursor doesn't support refactoring.
Not only that, I am already typing enough for coding, I don't want to type on chat windows as well, and so far the voice assistance is so so.
Fun story time!
Early in my career as a software engineer, I developed a reputation for speeding things up. This was back in the day where algorithm knowledge was just as important as the ability to examine the output of a compiler, every new Intel processor was met with a ton of anticipation, and Carmak and Abrash were rapidly becoming famous.
Anyway, the 22 year old me unexpectedly gets invited to a customer meeting with a large multinational. I go there not knowing what to expect. Turns out, they were not happy with the speed of our product.
Their VP of whatever said, quoting: "every saved second here adds $1M to our yearly profit". I was absolutely floored. Prior to that moment I couldn't even dream of someone placing a dollar amount on speed, and so directly. Now 20+ years later it still counts as one of the top 5 highlights of my career.
P.S. Mentioning as a reaction to the first sentence in the blog post. But the author is correct when she states that this happens rarely.
P.P.S. There was another engineer in the room, who had the nerve to jokingly ask the VP: "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?". They didn't laugh, although I thought it was quite funny. Hey, Doug! :)
> "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?"
I don't get it. Wouldn't going from 1 second to 0 seconds add the same amount of money to the yearly profit as going from 2 seconds to 1 second did? Namely, $1M.
> I don't get it. Wouldn't going from 1 second to 0 seconds add the same amount of money to the yearly profit as going from 2 seconds to 1 second did? Namely, $1M
Of course the joke was silly. But perhaps I should have provided some context. We were making industrial automation software. This stuff runs in factories. Every saved second shrinks the manufacturing time of a part, leading to increase of the total factory output. When extrapolating to abusrd levels, zero time to manufacture means infinite output per factory (sans raw materials).
yeah it's one of those things that are funny to the people saying it because they don't yet realize it doesn't make sense. I bet they felt that later, in the hotel room, in the shower, probably with a bottle of scotch.
8 replies →
A process taking 0 seconds means that, in one year, it can be run 31540000 sec/0 sec = ∞ times, multiplying the profit by ∞.
3 replies →
Working with a task scheduling system, we were told that every minute a airplane is delayed costs $10k. This was back in the 90s, so adjust accordingly.
So, did you make it faster?
Unfortunately, there wasn't a single bottleneck. A bunch of us, not just me, worked our asses off improving performance by a little bit in several places. The compounded improvement IIRC was satisfactory to the customer.
RE: P.P.S... God I love that humour. Actually was very funny.
if you ever remember that engineer's name you should tell them that I found the joke funny
Why do you count it as a highlight if your product failed to meet expectations?
> Rarely in software does anyone ask for “fast.”
They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++".
Watch HN for a while and you'll start to notice that "fast" is the only feature that is necessary to win over mindshare. It is like moths to a flame as soon as something says it is faster than what came before it.
Only in the small subset of programmers that post on HN is that the case. Most users or even most developers don't mind slow stuff or "getting into flow state" or anything like that, they just want a nice UI. I've seen professional data scientists using Github Desktop on Windows instead of just learning to type git commands for an easy 10x time save
GitHub Desktop is way better for reviewing diffs than the git cli. Everyone I’ve ever worked with who preferred cli tools also did an add and commit everything, and their PRs always have more errors overall that would be caught before even being committed if they reviewed visual diffs while committing.
2 replies →
They do mind, which is why we see such a huge drop off in retention if pages load even seconds too low. They just don't describe it in the same way.
They don't say they buy the iPhone because it has the fastest CPU and most responsive OS, they just say it "just works".
Not everyone is conscious about it but I feel like it’s something that people will always want.
Like the « evergreen » things Amazon decided to focus on : faster delivery, greater selection, lower cost.
You're taking the wrong conclusion, "Fast" is a winning differentiator only when you offer the same feature-set, but faster.
Your example says it, people will go, this is like X (meaning it does/has the same features as X), but faster. And now people will flock from X to your X+faster thing.
Which tells us nothing about if people would also move to a X+more-features, or a X+nicer-ux, or a X+cheaper, etc., without them being any faster than X or even possibly slower.
Really not sure about that. People will give up features for speed all the time. See git vs bzr/hg/svn/darcs/monotone,...
1 reply →
I hate it but it's true. Look at me, my fridge as an integrated tablet that tells me the weather outside. Never mind that it is a lil louder and the doors are creaky. It tells me the weather!
1 reply →
Maybe for languages, but fast is easily left behind when looking for frameworks. People want features, people want compatibility, people will use electron all over.
> fast is easily left behind when looking for frameworks.
Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day.
> People want features, people want compatibility
Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into "Hold up. What I'm currently using actually sucks. I'd better reconsider."
"Fast" is deemed important, but it isn't asked for as it is considered inconceivable that you wouldn't always make things "fast". But with that said, keep in mind that the outside user doesn't know what "fast" is until there is something to compare it with. That is how some products can get away with not being "fast" — until something else comes along to show that it needn't be that way.
7 replies →
And yet we live in a world of (especially web) apps that are incredibly slow, in the sense that an update in response to user input might take multiple seconds.
Yes, fast wins people over. And yet we live in a world where the actual experience of every day computing is often slow as molasses.
The trouble is that "fast" doesn't mean anything without a point of comparison. If all you have is a slow web app, you have to assume that the web app is necessarily slow — already as fast as it can be. We like to give people the benefit of the doubt, so there is no reason to think that someone would make something slower than is necessary.
"Fast" is the feature people always wanted, but absent better information, they have to assume that is what they already got. That is why "fast" marketing works so well. It reveals that what they thought was pretty good actually wasn't. Adding the missing kitchen sink doesn't offer the same emotional reaction.
5 replies →
Molasses can be fast if you leave it in the packet and hurl it!
Seriously though, you're so right- I often wonder why this is. If it's that people genuinely don't care, or that it's more that say ecommerce websites compete on so many things already (or in some cases maintain monopolies) that fast doesn't come into the picture.
Eh, I think the HN crowd likes fast because most tech today is unreasonably slow, when we know it could be fast.
It's infuriating when I have to use a chatbot, and it pretends to be typing (or maybe looking up a pre-planned generic response or question)...
I'm already pissed I have to use the damn thing, please don't piss me off more.
2 replies →
The claim was not that Rust was faster than C++, they said it’s about as fast.
C and C++ were and are the benchmark, it would have been revolutionary to be faster and offer memory safety.
Today, in some cases Rust can be faster, in others slower.
To a first approximation HN is a group of people who have convinced themselves that it's a high quality user experience to spend 11 seconds shipping 3.8 megabytes of Javascript to a user that's connected via a poor mobile connection on a cheap dual-core phone so that user can have a 12 second session where they read 150 words and view 1 image before closing the tab.
Fast is _absolutely not_ the only thing we care about. Not even top 5. We are addicted to _convenience_.
The fact that this article and similar ones get upvoted very frequently on this platform is strong evidence against this claim.
Considering the current state of the Web and user application development, I tend to agree with regard to its developers, but HN seems to still abide by other principles.
It's not that they convinced themselves, but that they don't know how to do any better. It is as fast as it can be to the extent of their knowledge, skill, and ability.
You see some legendary developers show up on HN from time to time, sure, but it is quite obvious that the typical developer isn't very good. HN is not some kind of exclusive club for the most prestigious among us. It is quite representative of a general population where you expect that most aren't very good.
This kind of slop is often imposed on developers by execs demanding things.
I imagine a large chunk of us would gladly throw all that out the window and only write super fast efficient code structures, if only we could all get well paid jobs doing it.
It's well known, but this video[1] is a proof of concept demonstration from 4 years ago, Casey Muratori called out Microsoft's new Windows Terminal for slow performance and people argued that it wasn't possible, practical, or maintainable to make a faster terminal and that his claims of "thousands of frames per second" were hyperbolic, and one person said it would be a "PHD level research project".
In response, Casey spent <1 week making RefTerm, a skeleton proto-terminal with the same constraints Microsoft people had - using Windows APIs for things, using DirectDraw with GPU rendering, handling terminal escape codes, colours, blinking, custom fonts, missing font character fallback, line wrap, scrollback, Unicode and Right-to-Left Arabic combining characters, etc. RefTerm had 10x faster throughput than Windows Terminal and ran at 6-7000 frames per second. It was single-threaded, not profiled, not tuned, no advanced algorithms, no-cheating by sending some data to /dev/null, all it had to speed it up was simple code without tons of abstractions and a Least Recently Used (LRU) glyph cache to avoid re-rendering common characters, written the first way that he thought of. Around that time he did a video series on that YouTube channel about optimization and arguing that even talking about 'optimization' was too hopeful, we should be talking about 'not-pessimization', that most software is not slow because it has unavoidable complexity and abstractions needed to help maintenance, it's slow because it's choked by a big pile of do-nothing code and abstraction layers added for ideological reasons which hurt maintenance as well as performance.
[1] https://www.youtube.com/watch?v=hxM8QmyZXtg - "How fast should an unoptimized terminal run?"
This video[2] is another specific details one, Jason Booth talking about his experience of game development, and practical examples of changing data layout and C++ code to make it do less work, be more cache friendly, have better memory access patterns, and run orders of magnitude faster without adding much complexity and sometimes removing complexity.
[2] https://www.youtube.com/watch?v=NAVbI1HIzCE - "Practical Optimizations"
I simultaneously love and hate watching Casey Muratori. Love because he routinely does things like this, hate because I have conversations like this entirely too often at work, except no one cares.
Someone posted their word game Cobble[1] on HN recently, the game gives some letters and the challenge is to find two English words which together use up all the given letters, and the combined two words to be as short as possible.
A naive brute-force solver takes the Cobble wordlist of 64k words and compares every word against every other word and does 64k x 64k = 4Bn loops and in the inner loop body, loops over the combined characters. If the combined words average 10 characters long, that's 40 billion operations just for the code structure, plus character testing and counting and data structures to store the counts. Seconds or Minutes of work for a puzzle that feels like any modern computer should solve it in microseconds.
It's always mildly intresting to me how a simple to explain problem, a tiny amount of data, and four lines of nested loop, can generate enough work to choke a modern CPU for minutes. Then considering how much work 3D games do in milliseconds. It highlights how impressive algorithmic research of the 1960s was to find ways to get early computers to do anything in a reasonable time, let alone find fast paths through complex problem patterns. Or perhaps, of all the zillions of possible problems which could exist, find any which can be approached by human minds and computers.
[1] https://news.ycombinator.com/item?id=44588699
Of course finding the optimal solution to a Cobble puzzle does not actually require the computation you describe. We can in a single pass find a limited set of candidate words and work out a solution with those.
1 reply →
I would have loved to live in a universe where we could replace the Windows Terminal with RefTerm - if only, to measure how many hours would pass before a Fortune 500 company has to halt operations, because RefTerm does not properly re- implement one of the subtle bugs creeping from one of the bazillion features that had made WinTerm slow over the years. [1]
[1] https://xkcd.com/1172/
I sighed when I read your comment, a comment which is exemplary of what Casey Muratori was ranting against - casual lazy dismissal of the idea that software can be faster, based on misunderstanding and lack of knowledge and/or interest, and throwing out the first objection that comes to mind as if it's an impassable obstacle. There were no bazillion features that made WinTerm slow over the years because Windows Terminal was a new product for Windows 10, released in 2019.[1]. There were piles of problems in Windows Terminal, Casey calls out that it didn't render Right-to-Left Arabic combining glyphs and it wasn't a perfect highly polished program from the outset. And it was an optional download, Fortune 500s wouldn't run it if they didn't want to.
RefTerm was explicitly not a production quality terminal and was not intended to be a replacement for Windows Terminal. RefTerm was a lower bound for performance of an untuned single-thread terminal. RefTerm was a proof of concept that if Microsoft had spent money and engineering skill on performance they could have profiled and used fancy algorithms and shortcuts and reimplemented slow Windows APIs with faster local ones, used threading, and improved on RefTerm's performance. A proof that "significantly faster terminals are unrealistic" is not true, that all the casual dismissals of why it's impossible are not the reasons for slowness, and that 10x better is an easily achievable floor, not a distant unreachable ceiling.
As a result of Casey's public shaming, Windows Terminal developers did improve performance.
[1] https://en.wikipedia.org/wiki/Windows_Terminal
Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast.
I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossible for me to skim the comments.
I think I tried it for about 3 days before I gave up, and I was a daily Slashdot reader before then.
HN is literally the website I open to check if I have internet connectivity. HN is truly a shining beacon in the trashy landscape of web bloat.
I like to use example.com/net/org
bonus, these have both http & https endpoints if you needed a differential diagnosis or just a means to trip some shitty airline/hotel walled garden into saying hello.
2 replies →
I usually load my blog to check internet connectivity.
I work at an e-waste recycling company. Earlier this week, I had to test a bunch of laptop docking stations, so I kept force refreshing my blog to see if the Ethernet port worked. Thing is, it loads so fast, I kept the dev tools open to see if it actually refreshed.
yep, I do exactly the same thing. If HN isn't loading, something is definitely fckd.
1 reply →
Oh it's lwn.net for me!
I find pinging localhost a bit more reliable, and faster too.
I blame HN switching to AWS. Downtime also increased after the switch.
1 reply →
The HN UI could do with some improvements, especially on mobile devices. The low contrast and small tap areas for common operations make it less than ideal, as well as the lack of dark mode.
I wrote my take on an ideal UI (purely clientside, against the free HN firebase API, in Elm): https://seville.protostome.com/.
To each their own, but I find the text for the number of points and "hours ago" extremely low contrast and hard to read on your site. More importantly, I think it emphasizes the wrong thing. I almost never really care who submitted a post, but I do care about its vote count.
1 reply →
Anyone who goes to the trouble of making their own HN front end is entitled to complain as much as they want, in my book! Nicely done.
1 reply →
Information density and ease of identification is the antithesis of "engagement" which often has some time on site metric they're hunting.
If you can find what you want and read it you might not spend 5 extra seconds lost on their page and thus they can pad their stats for advertisers. Bonus points if the stupid page loads in such a way you accidentally click on something and give them a "conversion".
Sadly financial incentive is almost always towards tricking people into doing something they don't want to do instead of just actually giving them what they fucking want.
> Sadly financial incentive is almost always towards tricking people into doing something they don't want to do instead of just actually giving them what they fucking want.
Northstar should be user satisfaction. For some products that might be engagement (eg entertainment service) while for others it is accomplishing a task as quickly as possible and exiting the app.
The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text.
HN might have over 100 chars per line of text. It could be better. I know I could do it myself, and I do. But "I fixed it for me" doesn't fix it for anyone else.
15 replies →
I don't think it was UI that killed Slashdot. The value was always in the comments, and in the very early years often there would be highly technical SMEs commenting on stories.
The site seemed to start to go downhill when it was sold, and got into a death spiral of less informed users, poor moderation, people leaving, etc. It's amazing that it's still around.
For me, Slashdot became full of curmudgeons. It’s pretty tiring when every “+5 Insightful” on a hard drive article questioning why you’d ever want so big of a drive, or why you’d require more than 256 colors or whatever new thing came out… like why are you even on a technology enthusiast site when you bitterly complain about every new thing? Basically either accept change or get left in the dust and slashdot’s crowd seemed determined to be left in the dust… forever loosing its relevance in the tech community.
Plus Rusty just pushed out Kuro5hin and it felt like “my scene” kind of migrated over.
As an aside, Kuro5hin was the only “large” forum that I ever bothered remembering people’s usernames. Every other forum it’s all just random people. (That isn’t entirely true, but true enough)
2 replies →
It's not bad. I still read it, but less than HN.
It brings me genuine joy to use websites like HN or Rock Auto that haven't been React-ified. The lack of frustration I feel when using fast interfaces is noticeable.
I don't really get why so many websites are slow and bloated these days. There are tools like SpeedCurve which have been around for years yet hardly anyone I know uses them.
It’s not modern UIs that prevent websites from being performant. Look at old.reddit.com, for instance. It’s the worst of both worlds. An old UI that, although much better than its newer abomination, is fundamentally broken on mobile and packed to the gills with ad scripts.
What changes have been made to the HN design since it was launched?
I know there are changes to the moderation that have taken place many times, but not to the UI. It's one of the most stable sites in terms of design that I can think of.
What other sites have lasted this long without giving in to their users' whims?
Over the last 4 years my whole design ethos has transformed to "WWHND" (What Would Hacker News Do?) every time I need to make any UI changes to a project.
Slashdot looked a lot like HN with high information density. It was fast and easy to read all the comments. Then a redesign happened because of web 2.0 or "mobile-first" hype and most of the comments got hidden/collapsed by default, sorted almost randomly etc. So a new user would come there and say "wtf this is a dead conversation" or would have to click too many times to get to the full conversation. So new user would leave, and so would the old ones because the page was so hard to use. It just lost users and that was that. All because of the redesign which they never wanted to revert. Sad really because I still think it had/has the best comment moderation by far.
2 replies →
The only one I remember is adding the ability to collapse comment threads
Ive wanted tp poll HN about how many people actively track usernames.
With IRC its basically part of the task, but every forum i read, its rare that i ever consider whose saying what.
I use this script: https://greasyfork.org/en/scripts/441566-hn-avatars-in-396-b...
Doesn't really help a ton with recognizing but it makes it easier to track within a thread.
Yep. Dang is basically the only one I notice.
1 reply →
I routinely notice a handful of people, such as Thomas Ptacek, whose opinions I have opinions about, and then in context I notice e.g. Martin Uecker for C and especially the pointer provenance problem (on which he has been diligently working for some years), or Walter Bright (for the D language), or Steve Klabnik (Rust)
There are people who show up much less often and have less obvious usernames, Andrew Ayer is agwa for example, and I'm sure there are people I blank on entirely.
Once in a while I will read something and realise oh, that "coincidental" similarity of username probably isn't a coincidence, I believe the first time I realised it was Martin Uecker was like that for example. "Hey, this HN person who has strong opinions about the work by Uecker et al has the username... oh... Huh. I guess I should ask"
HN goes to some lengths to de-emphasize the usernames, leaving them small and medium grey against a light grey background. It's not easy to track usernames here. Some other forums put far more emphasis on them, even letting users upload icons so you can tell who is who at a glance.
For me it's more a recognition after the fact thing: "Oh that was a good comment who said that? Oh that guy, yeah not surprised."
I don’t even slightly.
Similar thing happened (to me) with Hackaday around 2010-2011. I used to check it almost daily, and then never again after the major re-design.
That, and all the trolls that piled on, when CNN and YouTube started policing their comment sections.
HN interface is goated
Is that when they went fully xhtml?
orange site still doesn't support markdown link tags though.
What's a markdown link tag?
2 replies →
Fast is also cheap. Especially in the world of cloud computing where you pay by the second. The only way I could create a profitable transcription service [1] that undercuts the rest was by optimizing every little thing along the way. For instance, just yesterday I learned that the image size I've put together is 2.5× smaller than the next open source variant. That means faster cold boots, which reduces the cost (and providers a better service).
[1] https://speechischeap.com
ive approached the same thing but slightly differently. i can run it on consumer hardware for vastly cheaper than the cloud and don't have to worry about image sizes at all. (bare metal is 'faster') offering 20,000 minutes of transcription for free up to the rate limit (1 Request Every 5 Seconds)
https://geppetto.app
I contributed "whisperfile" as a result of this work:
* https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper....
* https://github.com/cjpais/whisperfile
if you ever want to chat about making transcription virtually free or so cheap for everyone let me know. I've been working on various projects related to it for a while. including open source/cross-platform superwhisper alternative https://handy.computer
> i can run it on consumer hardware for vastly cheaper than the cloud
Woah, that's really cool, CJ! I've been toying the with idea of standing up a cluster of older iPhones to run Apple's Speech framework. [1] The inspiration came from this blog post [2] where the author is using it for OCR. A couple of things are holding me back: (1) the OSS models are better according to the current benchmarks and (2) I have customers all over the world, so that geographical load-balancing is a real factor. With that said, I'll definitely spend some time checking out your work. Thanks for sharing!
[1] https://developer.apple.com/documentation/speech
[2] https://terminalbytes.com/iphone-8-solar-powered-vision-ocr-...
1 reply →
Is S3 slow or fast? It’s both, as far as I can tell and represents a class of systems (mine included) that go slow to go fast.
S3 is “slow” at the level of a single request. It’s fast at the level of making as many requests as needed in parallel.
Being “fast” is sometimes critical, and often aesthetic.
We have common words for those two flavors of “fast” already: latency and throughput. S3 has high latency (arguable!), but very very high throughput.
Well said. And it's not just the cloud. We self-host at my job and there are real cost savings to speed here too. Being able to continue using an old server for another year and having your staff be just a little more efficient adds up quickly.
Fast is cheap everywhere. The only reasons software isn’t faster:
* developer insecurity and pattern lock in
* platform limitations. This is typically software execution context and tool chain related more than hardware related
* most developers refuse to measure things
Even really slow languages can result in fast applications.
Yep. I'm hoping that installed copies of PAPER (at least on Linux) will be somewhere under 2MB total (including populating the cache with its own dependencies etc). Maybe more like 1, although I'm approaching that line faster than I'd like. Compare 10-15 for pip (and a bunch more for pipx) or 35 for uv.
Fast doesn't necessarily mean efficient/lightweight and therefore cheaper to deploy. It may just mean that you've thrown enough expensive hardware at the problem to make it fast.
Your CSS is broken fyi
Not in development and maintenance dollars it's not
Hmm… That's a good point. I recall a few instances where I went too far to the detriment of production. Having a trusty testing and benchmarking suite thankfully helped with keeping things more stable. As a solo developer, I really enjoy the development process, so while that bit is costly, I didn't really consider that until you mentioned it.
This is interesting. It got me to think. I like it when articles provoke me to think a bit more on a subject.
I have found this true for myself as well. I changed back over to Go from Rust mostly for the iteration speed benefits. I would replace "fast" with "quick", however. It isn't so much I think about raw throughput as much as "perceived speed". That is why things like input latency matter in editors, etc. If something "feels fast" (ie Go compiles), we often don't even feel the need to measure. Likewise, when things "feel slow" (ie Java startup), we just don't enjoy using them, even if in some ways they actually are fast (like Java throughput).
I feel the same way about Go vs Rust. Compilation speed matters. Also, Rust projects resemble JavaScript projects in that they pull in a million deps. Go projects tend to be much less dependency happy.
One of the Rust ecosystem's biggest mistakes, in my opinion, was not establishing a fiercely defensive mindset around dependency-bloat and compilation speed.
As much as Rust's strongest defenders like to claim, compilation speed and bloat just really wasn't a goal. That's cascaded down into most of the ecosystem's most used dependencies, and so most Rust ecosystem projects just adopt the mindset of "just use the dependency". It's quite difficult to build a substantial project without pulling in 100s of dependencies.
I went on a lengthy journey of building my own game engine tools to avoid bloat, but it's tremendously time consuming. I reinvented the Mac / Windows / Web bindings by manually extracting auto-generated bindings instead of using crates that had thousands of them, significantly cutting compile time. For things like derive macros and serialization I avoided using crates like Serde that have a massive parser library included and emit lots of code. For web bindings I sorted out simpler ways of interacting with Javascript that didn't require a heavier build step and separate build tool. That's just the tip of the iceberg I can remember off the top of my head.
In the end I had a little engine that could do 3D scenes, relatively complex games, and decent GPU driven UI across Mac, Windows, and Web that built in a fraction of the time of other Rust game engines. I used it to build a bunch of small game jam entries and some web demos. A clean release build on the engine on my older laptop was about 3-4 seconds, vastly faster than most Rust projects.
The problem is that it was just a losing battle. If I wanted Linux support or to use pretty much any other crate in the Rust ecosystem, I'd have to pull in dependencies that alone would multiple the compile time.
In some ways that's an OK tradeoff for an ecosystem to make, but compile times do impede iteration loops and they do tend to reflect complexity. The more stuff you're building on top of the greater the chances are that bugs are hard to pin down, that maintainers will burn out and move on, or that you can't reasonably understand your stack deeply.
Looking completely past the languages themselves I think Zig may accrue advantages simply because its initial author so zealously defined a culture that cares about driving down compile times, and in turn complexity. Pardon the rant!
3 replies →
And that leads to dependency hell once you realize that those dependencies all need different versions of the same crate. Most of the time this "just works" (at the cost of more dependencies, longer compile time, bigger binary)... until it doesn't then it can be tough to figure out.
In general, I like cargo a lot better than the Go tooling, but I do wish the Rust stdlib was a bit more "batteries included".
1 reply →
This is all well and good that we developers have opinions on whether Go compiles faster than Rust or whatever, but the real question is: which is faster for your users?
...and that sounds nice to me as well, but if I never get far enough to give it to my users then what good is fast binaries? (implying that I quit, not that Rust can't deliver). The holy grail would be to have both. Go is generally 'fast enough', but I wish the language was a bit more expressive.
I've noticed over and over again at various jobs that people underestimate the benefit of speed, because they imagine doing the same workflow faster rather than doing a different workflow.
For example, if you're running experiments in one big batch overnight, making that faster doesn't seem very helpful. But with a big enough improvement, you can now run several batches of experiments during the day, which is much more productive.
I think people also vastly underestimate the cost of context switching. They look at a command that takes 30 seconds and say "what's the point of making it take 3 seconds? you only run it 10 times in a day; it's only 5 minutes". But the cost is definitely way more than that.
Me, looking at multi-hour CI pipelines, thinking how many little lint warnings I'd fix up if CI could run in like 20 minutes
Whenever we make our code faster the users just run bigger models :P.
Pavel Durov (founder of Telegram) totally nailed this concept.
He pays special attention to the speed of application. The Russian social network VK worked blazingly fast. The same is about Telegram.
I always noticed it but not many people verbalized it explicitly.
But I am pretty sure that people realize it subconsciously and it affects user behaviour metrics positively.
Telegram is pretty slow, both the web interface and the Android app. For example, reactions to a message always take a long time to load (both when leaving one, and when looking at one). Just give me emoji, I don't need your animated emoji!
Can't agree.
These operations are near instant for me on telegram mobile and desktop.
It's the fastest IM app for me by a magnitude.
[flagged]
Website is superfast. Reason I usually go for the comments first on HN is exactly this: they're fast. THIS is notably different.
On interfaces:
It's not only the slowness of the software or machine we have to wait for, it's also the act of moving your limb that adds a delay. Navigating a button (mouse) adds more friction than having a shortcut (keyboard). It's a needless feedback loop. If you master your tool all menus should go away. People who live in the terminal know this.
As a personal anecdote, I use custom rofi menus (think raycast for Linux) extensively for all kinds of interaction with data or file system (starting scripts, opening notes, renaming/moving files). It's notable how your interaction changes if you remove friction.
Venerable tools in this vein: vim, i3, kitty (former tmux), ranger (on the brim), qutebrowser, visidata, nsxiv, sioyek, mpv...
Essence of these tools is always this: move fast, select fast and efficiently, ability to launch your tool/script/function seamlessly. Be able to do it blindly. Prefer peripheral feedback.
I wish more people saw what could be and built more bicycles for the mind.
The website is fast because it's minimal, just under 80 kB of which 55 is the custom font; this is fine for plain content sites, but others will have other requirements.
There's never a reason to make a content website use heavyweight JS or CSS though.
That’s actually why I don’t like discourse at all. If your community site needs loading icons I don’t want to use it.
is it a hand coded website in this day and age?!
> Rarely in software does anyone ask for “fast.” We ask for features, we ask for volume discounts, we ask for the next data integration. We never think to ask for fast.
Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company.
At companies that had us target metrics, speed and latency was always a metric.
I don’t think my experience has been all that unique. In fact, I’d be more surprised if I joined a company and they didn’t care about how responsive the product felt, how fast the pages loaded, and any weird lags that popped up.
At 6 out of 8 companies I've worked at (mostly a mixture of tech & finance) I have always had to fight to get any time allotted for performance optimization, to the point where I would usually just do it myself under the radar. Even at companies that measured latency and claimed it was important, it would usually take a backseat to adding more features.
That is how it is most of the time. If you want to experience the other extreme, go to HFT or low-latency projects.
My experience has been that people sometimes obsess over speed for things like how fast a search result returns but not over things like how fast a page renders or how many bites we send the user.
I have been paid to make things fast. Sometimes that was the explicit reason I was hired!
I find most jobs I had fast becomes a big issue once things are too slow. Or expensive.
It's a retroactively fixed thing. Like imagine forgetting to make a UI, shipping just an API to a customer then thinking "oh shit, they need a UI they are not programmers". And only noticing from customer complaints. That is how performance is often treated.
This is probably because performance problems usually require load or unusual traffic patterns, which require sales, which require demos, which dont require performance tuning as there is one user!
If you want to speed your web service up first thing is invest time, maybe money in really good observability. Should be easy for anyone in the team to find a log, see what CPU is at etc. Then set up proxy metrics around speed you care about and talk about them every week and take actions.
Proxy metrics means you likely cant (well probably should not) check the speed that Harold can sum his spreadsheet every minute, but you can check the latency of the major calls involved. If something is slow but metrics look good then profiling might be needed.
Sometimes there is an easy speed up. Sometimes you need a new architecture! But at least you know what's happening.
In addition to all this, I’m also of the opinion that most users just have software “lumped on them” and have little to no recourse for complaint, so they’re just forced/trained to put-up-and-shut-up about it.
As a result, performance (and a few other things) functionally never gets “requested”. Throw in the fact that for many mid-to-large orgs, software is not bought by the people who are forced to use it and you have the perfect storm for never hearing about performance complaints.
This in turn, justifies never prioritising performance.
No mention of google search itself being fast. It's one of the poster children of speed being part of the interface.
Microsoft needs to take heed, for example Explorer's search, Teams, make your computer seem extremely slow. VS Code on the other hand is fast enough, while slower than native editors such as Sublime Text.
Efficient code is also environmentally friendly.
First, efficient code is going to use less electricity, and thus, fewer resources will need to be consumed.
Second, efficient code means you don't need to be constantly upgrading your hardware.
Well, that depends. Very inefficient code tends to only be used when absolutely needed. If an LLM becomes ten times faster at answering simple prompts, it may very well be used a hundred times more as a result, in which case electricity use will go up, not down. Efficiency gains commonly result in doing way more with more, not more with less.
Correct. This is also known as a rebound effect [1], or, specifically with regard to technological improvements, as the Jevons paradox [2].
[1]: https://en.wikipedia.org/wiki/Rebound_effect_(conservation)
[2]: https://en.wikipedia.org/wiki/Jevons_paradox
Indeed, that is a common occurrence that called Jevons Paradox.
Energy used for lighting didn't decrease when the world moved to LED lights which use much less energy - instead we just used more lighting everywhere, and now cities are white instead of yellow.
I know what you mean, but do you have a citation for that? LEDs are so much more efficient that I wonder if its true.
Very true, but in recent years feature development has taken precedence over efficiency. VP of whatever says hardware is cheap, software engineers are not.
Unless your code is running on a large number of machines across data centers that energy is about 2-3 figures a month in total utilization.
So if we use cost as a proxy for environment impact it’s not saving much at all.
I think this is a meme to help a different audience care about performance.
The industry (hint:this forum's readers) have replaced "fast" software with "portable" meaning -universally addressable libraries that must load from discrete and often remote sources, -zero hang time in programming language evolution (leaving no time for experts to discover, document, and implement optimizations) -insistence on "the latest version" focused software with no emphasis on long term code stability
Only sorta related, but it’s crazy that to me how much our standards have dropped for speed/responsiveness in some areas.
I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game.
Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable.
> I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable
Your experience is not normal.
If you’re seeing that much lag, the most likely explanation is your display. Many TVs have high latency for various processing steps that doesn’t matter when you’re watching a movie or TV, but becomes painful when you’re playing games.
This does not undermine chamomeal's argument. The whole point is that back in the N64 days, they could not possibly have had that experience. There was no way to even make it happen. The fact that today it's a real possibility when you've done nothing obviously wrong is a definite failure.
3 replies →
Luckily newer TVs and console can negotiate a low-latency mode automatically. It's called ALLM (Auto-Low Latency Mode).
it's possible, but it seems to specifically be a rocket league on xbox series s problem, not a display problem. Other games run totally fine on the same display with no lag!
That may be an issue of going from a CRT tv to an LCD tv. As far as I am aware there was no software manipulation of the video input on a CRT. It just took the input and displayed it on the screen in the only way it could. Newer tvs have all kinds of settings to alter the video which takes processing time. They also typically have a game mode to turn off as much of it as it will allow.
Why should the user care whether the lag is introduced by the software in the controller, or the software in the gaming console, or the software in the tv.
The lag is due to some software. So the problem is with how software engineering as a field functions.
I hear it claimed that you're only supposed to enable game mode for competitive multiplayer games -- but I've found that many single player games like Sword Art Online: Fatal Bullet are unplayable without game mode enabled.
It could be my unusual nervous system. I'm really good at rhythm games, often clearing a level on my first try and amazing friends who can beat me at other genres. But when I was playing League of Legends, which isn't very twitchy, it seemed like I would just get hit and there was nothing I could do about it when I played on a "gaming" laptop but found I could succeed at the game when I hooked up an external monitor. I ran a clock and took pictures showing that the external monitor was 30ms faster than the built-in monitor.
It’s not just the software, the analog electronics of LCD/LED screens are inherently laggy and have motion blur: https://en.wikipedia.org/wiki/Sample_and_hold
How about the speed of going from a powered off console to playing the actual game? Sleep mode helps with resuming on console, but god forbid you’re on a pc with a game that has anti cheat, or comped menus. You will sit there, sometimes for a full minute waiting. I absolutely cannot stand these games.
My buddy booted up his PC after gaming on his PS5 for two weeks and every single app needed multi-gig updates. Xbox app, Logitech app, Discord, Windows 11, Chrome, Steam. The whole enchilada. Rage inducing compared to sticking a cart in an N64.
Or how channel surfing now requires a 1-2 second latency per channel, versus the way it was seemingly instant from the invention of television through the early 1990s.
Having a lot more channels is cool I guess, but it was much better to watch and listen to a staticy analog channel 20 years ago, than a digital channel today where there is no audio and the image freezes.
Heck yes! I recently dusted off (had to literally dust the inside of the cartridges to get past a black screen, lol) my old Sega Genesis (and bought an HDMI adaptor for it), and have been letting my school age sons play it. They haven't even commented on the basic graphics. They're like "wow dad, no boot time, no connecting to server time, no waiting to skip ads time". They love it.
How about you enable game mode on the TV you're using
Game mode is on! The input log is not with the display. Other games run fine.
I was going to say one of the more recent times fast software excited me was with `uv` for Python packaging, and then I saw that op had a link to Charlie Marsh in the footnote. :)
I once accidentally blocked TCP on my laptop and found out "google.com" runs on UDP, it was a nice surprise.
baba is fast.
I sometimes get calls like "You used to manage a server 6 years ago and we have an issue now" so I always tell the other person "type 'alias' and read me the output", this is how I can tell if this is really a server I used to work on.
fast is my copilot.
Specifically HTTP/3 and QUIC (which came out of Google):
https://en.wikipedia.org/wiki/HTTP/3
https://en.wikipedia.org/wiki/QUIC
They don't require you to use QUIC to access Google, but it is one of the options. If you use a non-supporting browser (Safari prior to 2023, unless you enabled it), you'd access it with a standard TCP-based HTTP connection.
> this is how I can tell if this is really a server I used to work on
Hm, shell environment is fairly high on the list of things I'd expect the next person to change, even assuming no operational or functional changes to a server.
And of course they'd be using a different user account anyway.
A lot of people have low expectations from having to use shit products at work, and generally not being discerning.
Speed is what made Google, which was a consumer product at the time. (I say this because it matters more in consumer products.)
I don’t think people realize how much working with bad tools inspired you to write equally bad applications.
Beautiful tools make you stretch to make better things with them.
Fast is a distinctive feature.
For what is worth I built myself a custom jira board last month, so I could instantly search, filter and group tickets (by title, status, assignee, version, ...)
Motivation: Running queries and finding tickets on JIRA kills me sometimes.
The board is not perfect, but works fast and I made it superlightweight. In case anybody wants to give it a try:
https://jetboard.pausanchez.com/
Don't dare to try on mobile, use desktop. Unfortunately it uses a proxy and requires an API key, but doesn't store anything in backend (just proxies the request because of CORS). Maybe there is an API or a way to query jira cloud instance directly from browser, I just tried first approach and moved on. It even crossed my mind to add it somehow to Jira marketplace...
Anyway, caches stuff locally and refreshes often. Filtering uses several tricks to feel instant.
UI can be improved, but uses a minimalistic interface on purpose, like HN.
If anybody tries it, I'll be glad to hear your thoughts.
My favorite essay on this topic, not yet referenced, is James Somers's "Speed matters:" https://jsomers.net/blog/speed-matters
Discussed a few times:
Working quickly is more important than it seems (2015) - https://news.ycombinator.com/item?id=10020827 - Aug 2015 (139 comments)
jsomers gets a lot of much-deserved love here!
>> Rarely in software does anyone ask for “fast.”
I have been asking about Latency-Free Computing for a very long time. Every Computing now is slow.
make fast sexy again... please growing up I've thoroughly enjoyed seeing workers tapping away at registers where it doesn't have a mouse, all muscle memory and layers and layers of menu accessible by key taps, whether it's airline, clothing store, even some restaurant used to have those dimly lit terminals glowing green or orange with just bunch of text and a well versed operator chatting while getting their work done. the keys were commercial grade mechanical which made pleasing sound.
nowadays it's fancy touch display, requires concentration and often sluggish, and the machine often felt cheap and made cheap sound when tapped on, I don't think the operator are ever enjoying interacting with it and the software's often slow across the network....
I'm all for fast. It shows no matter what, at least somebody cared enough for it to be blazing fast.
Reminds me "Fast Software, the Best Software" by Craig Mod: https://craigmod.com/essays/fast_software/
> Developers ship more often when code deploys in seconds (or milliseconds) instead of minutes.
I don't want my code deployed in seconds or milliseconds. I'm happy to wait even an hour for my deployment to happen, as long as I don't have to babysit it.
I want my code deployed safely, rolled out with some kind of sane plan (like staging -> canary -> 5% -> 20% -> 50% -> 100%), ideally waiting long enough at each stage of the plan to ensure the code is likely being executed with enough time for alerts to fire (even with feature flags, I want to make sure there's no weird side effects), and for a rollback to automatically occur if anything went wrong.
I then want to enable the feature I'm deploying via a feature flag, with a plan that looks similar to the deployment. I want the enablement of the feature flag, to the configured target, to be as fast as possible.
I want rollbacks to be fast, in-case things go wrong.
Another good example is UI interactions. Adding short animations to actions makes the UI slower, but can considerably improve the experience, by making it more obvious that the action occurred and what it did.
So, no, fast isn't always better. Fast is better when the experience is directly improved by making it fast, and you should be able to back that up with data.
This is one of the reasons I switched from Unity to Godot. There is something about Godot loading fast and compiling fast that makes it so much more immersive to spend hours chugging away at your projects for.
My son told me to not develop a game with Unity because, as a player, he thought Unity games took way too long to load.
There might be some selection bias - Experienced programmers who care a lot about engine technology are more likely to use Godot and also optimize their load times. Unity includes a lot of first-time programmers who just want to get something shipped
I always have to remind myself of the bank transfer situation in the US whenever I read an article complaining about it. Here in the UK, bank transfers are quick and simple (the money appears to move virtually instantly). Feel free to enlighten me to why they're so slow in the US.
"Community banks mostly don’t have programmers on staff, and are reliant on the so-called “core processors” ...
This is the largest reason why in-place upgrades to the U.S. financial system are slow. Coordinating the Faster ACH rollout took years, and the community bank lobby was loudly in favor of delaying it, to avoid disadvantaging themselves competitively versus banks with more capability to write software (and otherwise adapt operationally to the challenges same-day ACH posed)."
From the great blog Bits About Money: https://www.bitsaboutmoney.com/archive/community-banking-and...
UK Banks use FiServ too. So that can't be the only reason.
For ACH, it's the scheduling and batching that makes it slow. The transfer itself should be instant but often my bank sends it out around midnight. This is why Venmo and Zelle are so popular. You can also modify/cancel a bank transfer before it goes through, which is nice.
This is the same in Switzerland. If you request an IBAN transfer, it's never instant. The solution there for fast payments is called TWINT, which works at almost POS terminal (you take a picture of the displayed QR code).
I think BACS is similarly "slow" due to the settlement process.
These days ACH settlement runs multiple times a day. The biggest source of delay for ACH transfers is your bank delaying release of the funds for risk management. ACH transfers can be reversed even after they have "settled" and if the receiving bank has already disbursed the funds then they have to eat the cost of reimbursing the sender. Reversals are more likely to happen soon after the transfer completes, so delaying release of the funds makes it less likely the bank will be left holding the bag.
People are almost always talking about Faster Payments [0] rather than BACS. It really is instant.
[0] https://en.m.wikipedia.org/wiki/Faster_Payment_System_(Unite...
2 replies →
The US actually has two real-time payment systems: RTP and FedNow. The number of participating banks is growing rapidly.
https://real-timepayments.com/Banks-Real-Time-Payments.html
Prior to that, you could get instant transfers but it came with a small fee because they were routed through credit card networks. The credit card networks took a fee but credit card transactions also have different guarantees and reversibility (e.g. costing the bank more in cases of fraud)
From the linked RTP site: "Because of development and operational costs most banks and credit unions will offer "send only" capabilities"
Which means nobody can send me money.
FedNow on the backend is supported by fewer banks than Zelle is, which is probably why hardly any banks expose a front-end for it.
I am convinced that this is in some cases a pro-consumer behavior. A credit card company once pulled money from my bank via ACH due to the automatic payment feature I set up, but that bank account didn't have enough money in it. The bank sent me at least two emails about the situation. I finally noticed that second email and wired myself more money from a different account. The credit card company didn't notice anything wrong and didn't charge any late fees or payment returned fees. The bank didn't charge any overdraft fees or insufficient funds fees. And the wire transfer didn't have a fee due to account balance. (Needless to say, from then on I no longer juggle multiple bank accounts like that.)
The bank had an opportunity to notify me precisely because ACH is not real time. And I had an opportunity to fix it because wire transfers is almost real time (finishes in minutes not days). I appreciate it when companies pull money from my account I get days of notice but if I need to move money quickly I can do it too.
In most cases it's definitely better for it to be fast. For example I sold a buggy face to face today and they paid me by bank transfer, and the reason we could do that was that I had a high confidence it would turn up quickly and they weren't trying to scam me. It actually took around 1 second which is really quite fast.
You don't need slow transfers to get an opportunity to satisfy automatic payments. I don't know how it works but in the UK direct debits (an automatic "take money from my account for bills" system) gives the bank a couple of days notice so my banking app warns me if I don't have enough money. Bank transfers are still instant.
Here in Switzerland bank transfers only take place during business hours
I believe this is because Ürs has to load my silver pieces onto the donkey and drive it to the other bank.
We're pretty lucky here in Australia. Over the past decade or so, PayID has been successfully rolled out to virtually all banks, giving us free and (usually) instant money transfers - I'd say more than half of all personal payments are now done with PayID. Old-skool bank transfers are still the norm for business and administrative payments, but that's changing too, and in any case, those transfers are increasingly being executed behind the scenes over Osko (aka PayID), so they end up settling in seconds (or at least hours) instead of days.
IS IT NOW!? last time I visited (long time ago) it was BACS, and the bank clerk told me it takes one day to "properly" register they've received my fund, one day to make sure it transferred and on the third and final day, the other bank can "properly" acknowledge they've received the fund thus why it took 3 FRIGGIN DAYS. I used so much cash back then.
patio11 wrote a bit about that here: https://www.bitsaboutmoney.com/archive/the-long-shadow-of-ch...
Isn't there a law in the UK which says it must be fast?
[dead]
I think that people generally underestimate what even small increases in the interaction time between human and machine cost. Interacting with sluggish software is exhausting, clicking a button and being left uncertain whether it did anything is tedious and software being fast is something you can feel.
Windows is the worst offender here, the entire desktop is sluggish even though it there is no computational task which justifies those delays.
There's that wondering if the UI input was registered at all and the mental effort to suppress clicking again when you expect a delayed response.
Apple software, especially lately, can be really bad for it too. Single core perf is slightly better on my iPad than my MacBook Pro and yet everything feels an order of magnitude slower. If I am impatiently tapping the space I know a button will appear waiting for an animation to finish, some aspect of software design has gone horribly awry.
iOS (iPhone, iPad) UI is typically smooth and fast though. If only car navigation and UI could be as responsive.
I wish I could live in a world of fast.
C++ with no forward decls, no clang to give data about why the compile time is taking so long. 20 minute compiles. Only git tool I like (git-cola) is written in Python and slows to a crawl. gitk takes a good minute just to start up. Only environments are MSYS which is slow due to Windows, and WSL which isn't slow but can't do DPI scaling so I squint at everything.
I might get down voted for saying this on HN, but I'll still say it.
As C++ devs we used to complain a lot about it's compilation speed. Now after moving to Rust, sometimes we wish we could just go back to C++ due to Rust's terrible compilation speeds! :-)
The web is fast.
> Rarely in software does anyone ask for “fast.”
I don't think I can relate this article to what actually happened to the web. It went from being an unusable 3D platform to a usable 2D one. The web exploded with creativity and was out of control thanks to Flash and Director, but speeds were unacceptable. Once Apple stopped supporting it, the web became boring, and fast, very fast. A lot of time and money went into optimising the platform.
So the article is probably more about LLMs being the new Flash. I know that sounds like blasphemy, but they're both slow and melt CPUs.
The web might be fast compared to in 2005 but only if you don't normalize for average CPU performance and bandwidth. Websites that are mostly text often still manage to take remarkable amounts of time to finish rendering and stop moving things around.
> Rarely in software does anyone ask for “fast.”
> But software that's fast changes behavior.
I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other.
My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.
"The only way to go fast, is to go well." ― Robert C. Martin
Software that goes fast changes human behavior. It seems you’re thinking it changes the software’s behavior. Not sure. Either that, or I don’t follow your comment at all.
I'm not really sure how to rephrase it, so I can try an example.
Lets say that the author has a machine that is a self contained assembly line, it produces cans of soup. However, the machine has a problem - every few cans of soup, one can comes out sideways and breaks the machine temporarily, making them stop and unjam it.
The author suggests to double the speed of the machine without solving that problem, giving them their soup cans twice as fast, requiring that they unjam it twice as often as well.
I believe that (with situation exceptions) this is a bad approach, and I would address the problem causing the machine to get jammed before I doubled the speed of the machine
That being said, this is a very simplistic view of the situation, in a real situation either of these solutions has a number of variables that may make it preferable over the other - my gripe with the piece is that the author suggests the "faster" approach is a good default that is "simple", "magical" and "fun". I believe it is shortsighted, causes compounding problems the more it is applied in sequence, and is only "magical" if you bury your head in the sand and tell yourself the problems are for someone else to figure out - which is exactly what the author handwaves away at the end, with a nebulous allusion to some future date when these tools that we should accept because they are fast will eventually be made good by some unknown person.
> Asking an LLM to research for 6 minutes is already 10000x faster than asking for a report that used to take days.
Assuming, like, three days, 6 minutes is 720x faster. 10000x faster than 6 minutes is like a month and a half!
More like 300x if you count working hours. Although I've yet to see anything that would take a person a few days (assuming the task is worth spending a few dats on) and that an LLM could do in six minutes, even with human assistance.
Very much the opposite in my experience. People, especially on this site, ask for "fast" regardless of whether they need it. If asked "how fast?" the answer is always "as fast as possible". And they make extremely poor choices as a result. Fast is useful up to a point, but faster than that is useless - maybe actively detrimental if you can e.g. generate research reports faster than you can read them.
You make much better code, and much better products, if you "fast" from your vocabulary. Instead set specific, concrete latency budgets (e.g. 99.99% within x ms). You'll definitely end up with fewer errors and better maintainability than the people who tried to be "fast". You'll often end up faster than them too.
I’m senior developer on a feature bloated civil engineering web app that has 2 back end servers (one just proxies to the other) and has 8k lines of stored procedures as the data layer and many multi k line react components that intentionally break react best practices.
I loathe working on it but don’t have the time to refactor legacy code.
———————-
I have another project that I am principal engineer and it uses Django, nextjs, docker compose for dev and ansible to deploy and it’s a dream to build in and push features to prod. Maybe I’m more invested so it’s more interesting to me but also not waiting 10 seconds to register and hot reload a react change is much more enjoyable.
whats your setup for the frontend? do you autogen your queries from DRF? do you prefer react headless over django templates?
If it’s something simple, I’ll use Django template because it’s very easy. Most stuff I work on these days requires more fancy ui so I’ll 100% use react or nextjs for front end (and I’ve be using zustand for state management). I’ll have an api util that uses axios and handles appending a jwt auth header to all requests and use that in my components. I like using Django-all-auth because it makes integrating email/google/microsoft auth really easy out of the box.
DRF is good, ninja is a little more light weight and flexible so it really comes down to the project.
> it's obvious to anyone that writes code that we're very far from the standards that we're used to
This is true, but I also think there's a backlash now and therefore some really nice mostly dev-focused software that is reeaaaaly fast. Just to name a few:
- Helix editor - Ripgrep - Astral python tools (ruff, uv, ty)
That's a tiny subsection of the mostly bloated software that exists. But it makes me happy when I come across something like that!
Also, browsers seems to be really responsive despite being one of the most feature bloated products on earth thanks to expanding web standards. I'm not really counting this though because Firefox and Chrone might rarely lag, the websites I view with them often do, so it's not really a fast experience.
>> Rarely in software does anyone ask for “fast.”
I don't know, there are a sizeable subset of folks who value fast, and it's a big subset, it's not niche.
Search for topics like turning off animations or replacing core user space tools with various go and rust replacements, you'll find us easily enough.
I'm generally a pretty happy MacOS user, especially since M1 came along. But I am seriously considering going back to linux again. I maintain a parallel laptop with nixos and i'm finding more and more niggles on the mac side where i can prioritise lower friction on linux.
> Instagram usually works pretty well—Facebook knows how important it is to be fast.
Fast is indeed magical, that's why I exclusively browse Instagram from the website; it's so slow I dip out before they get me with their slot machine.
The owner of this site is involved in a scrapping business[0]. How can she justify that with fast-ness?
>Performant stealth mode
>Scale browsers with bot anti-detection. Access high performant residential proxies and built-in auto-CAPTCHA solvers
[0] https://www.onkernel.com/#:~:text=Performant%20stealth%20mod...
Highly Agree.
Speed of all kinds is incredibly important. Give me all of it.
- Fast developers
- Fast test suites
- Fast feedback loops
- Fast experimentation
Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".
As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every other deficiency.
- It makes engineering mistakes cheaper (just fix them fast)
- It make product experimentation easy (we can test this fast and revert if needed)
- It makes developers ramp up quickly (shipping code increases confidence and knowledge)
- It actually makes rigor more feasible as the most effective rigorous processes are light weight and built-in.
Every line of code is a liability, the system that enables it to change rapidly is the asset.
Side note: every time I encounter JVM test startup lag I think someday I am going to die and will have spent time doing _this_.
For inspiration in this direction see Patrick Collison's great list: https://patrickcollison.com/fast
Another benefit of speed in this regard is that it lets you slow down a bit more and appreciate other things in life.
> Someone (Napoleon?) is credited with saying "quantity has a quality all its own"
Joe Stalin, I believe. It's a grim metaphor regarding the USSR's army tactics in WW2.
https://www.goodreads.com/quotes/795954-quantity-has-a-quali...
According to Wikiquotes, this is a common misattribution, and the first known record is Ruth M. Davis from 1978, who attributes it to Lenin: https://en.wikiquote.org/wiki/Quantity
I feel like this should have some kind of "promotional" or "ad" label. I agree wholeheartedly with the words here, but I also note that the author is selling the fast developer tools she laments the dearth of: https://www.catherinejue.com/kernel
Again, no ill will intended at all, but I think it straddles the promotional angle here a bit and maybe people weren't aware
The tool in question is also a fairly unethical scraping and botting tool, advertising defrauding services to bypass captchas and scrape websites against the owners' wishes.
Why's this so highly rated. Y'all don't know that fast is good?
guess everybody misses software that you can tell the maker cares...
My sites. In order of increasing complexity. Are they fast?
https://magarshak.com
https://miracles.community
https://qbix.com
https://intercoin.app
Here is some extensive advice for making complex websites load extremely quickly
https://community.qbix.com/t/qbix-websites-loading-quickly/2...
Here is also how to speed up APIs:
https://community.qbix.com/t/building-efficient-apis-with-qb...
One of the biggest things our framework does as opposed to React, Angular, Vue etc. is we lazyload all components as you need them. No need for tree-shaking or bundling files. Just render (static, cached) HTML and CSS, then start to activate JS on top of it. Also helps massively with time to first contentful paint.
https://community.qbix.com/t/designing-tools-in-qbix-platfor...
All this evolved from 2021 when I gave this talk:
http://www.youtube.com/watch?v=yKPKuH6YCTc
How did over a thousand people upvote this hollow article? Am I the only one who was looking for substance in vain?
The substance is in the audience, in the sense that a lot of people resonate with what the article is saying.
> Superhuman's sub-100ms rule—plus their focus on keyboard shortcuts—changed the email game in a way that no one's been able to replicate, let alone beat.
https://blog.superhuman.com/superhuman-is-being-acquired-by-...
Being fast helps, but is rarely a product.
I often hear this sort of thing "Facebook was a success using PHP therefore language choice isn't important" or in this case "superhuman made their product fast and they still failed so speed isn't important".
It's obviously wrong if you think about it for more than a second. All it shows is that speed isn't the only thing that matters but who was claiming that?
Speed is important. Being slow doesn't guarantee failure. Being fast doesn't guarantee success. It definitely helps though!
>Being fast helps, but is rarely a product.
>Being fast doesn't guarantee success.
Sometimes it can be a deciding factor though.
Also sometimes speedyness or responsiveness beyond nominal is not as much of a "must have" compared to nominally fast performance in place of sluggishness.
1 reply →
> Rarely in software does anyone ask for “fast.”
As some working on embedded audio DSP code I just had to laugh a little.
Yes, there is a ton of code that has a strict deadline. For audio that may be determined by your buffer size — don't write your samples to that buffer fast enough and you will hear it in potentially destructively loud fashion.
This changes the equation, since faster code now just means you are able to do more within that timeframe on the same hardware. Or you could do the same on cheaper hardware. Either way, it matters.
Similar things apply to shader coding, game engines, control code for electromechanical systems (there, missing the deadline can be even worse).
> When was the last time you used airplane WiFi and actually got a lot done?
The greatest day of productivity in my life was a flight from Melbourne to New York via LAX. No wifi on either flight, but a bit in transit. Downloaded everything I needed in advance. Coded like a mofo for like 16 hours.
Fast internet is great for distractions.
Same here. I am more productive on a plane than anywhere else. And for the reasons you describe.
Speed is the most fundamental feature. Otherwise we could do everything by hand and need no computers.
Back in the 90's I ran a dev team building Windows applications in VB, and had the rule that the dev machines had to be lower-specced than the user machines they were programming for.
It was unpopular, because devs love the shiny. But it worked - we had nice quick applications. Which was really important for user acceptance.
I didn't make this rule because I hated devs (though self-hatred is a thing ofc), or didn't want to spend the money on shiny dev machines. I made it because if a process worked acceptably quickly on a dev machine then it never got faster than that. If the users complained that a process was slow, but it worked fine on the dev's machine, then it proved almost impossible to get that process faster. But if the dev experience of a process when first coding it up was slow, then we'd work at making it faster while building it.
I often think of this rule when staring at some web app that's taking 5 minutes to do something that appears to be quite simple. Like maybe we should have dev servers that are deliberately throttled back, or introduce random delays into the network for dev machines, or whatever. Yes, it'll be annoying for devs, but the product will actually work.
> Like maybe we should have dev servers that are deliberately throttled back
This is a good point. Often datasets are smaller in dev. If a reasonable copy of live data is used, devs would have an intuition of what is making things slow. Doesn't work for live data that is too big to replicate on a developer's setup though.
I work on optimization a large fraction of my time. It is not something learned in a week, month or even a year.
At least in B2B applications that rely heavily on relational data, the best developers are the ones who can optimize at the database level. Algorithmic complexity pretty much screams at me these days and is quickly addressed, but getting the damned query plan into the correct shape for a variety of queries remains a challenge.
Of course, knowing the correct storage medium to use in this space is just as important as writing good queries.
Superhuman achieved their sub-something speed maybe (has anyone measured it except them? Genuinely, post a link, appreciated)
However the capital required will probably never happen again in relation to the return for any investor involved in that product.
Props to them for pushing the envelope, but they did it in the zero interest era and its a shame this is never highlighted by them. And now the outcome is pretty clear in terms of where the company has ended up.
The flip-side of this is that if something is too fast, it raises doubts about whether it actually happened at all. I'm reminded of the TurboTax case, where Intuit found that adding a bunch of artificial loading screens to make it look like TurboTax was taking its time to really pore over customers' tax returns ended up being more appealing to users than not doing so. The actual "analyses" happen within less than a second, but that was (allegedly) too fast for users to believe.
A ticket booking system I was familiar with added latency after upgrades to maintain a particular experience for the operators.
I guess they were used to typing stuff then inspecting paperwork or other stuff waiting for a response. Plus, it avoided complaints when usage inevitably increased over time.
That’s an unusual case because most customers use it once a year, and speed is number 3 or 4 on their priorities behind getting it right (not getting in trouble), and understanding wtf is going on.
What's amazing to me is that often all it takes to go fast is to keep things simple. JBlow once said that software should be treated like a rocket ship: every thing you add contributes weight.
Linus Torvalds said exactly that in a talk about git years ago. It's crazy to think back how people used to use version control before git. Git totally changed how you can work by being fast.
Fast and light weight. That's why I love vim/cli over IDEs.
Btw, cool site design.
Interesting that onkernel.com intentionally animates and slows down the loading of the web interface, making it harder to scroll and scan the site. Irony or good design?
The article makes two points—one about software performance, the other about development performance. On the topic of software performance, I think the best explanation I got came from the great Prof. Charles Leiserson’s MIT course on performance engineering: performance is a currency. It’s something we spend to gain other qualities—safety, rich features, user-friendliness, and so on. At the end of the day, a computer can executes about 100 simple primitve instructions. The reason we have a software industry is because of speed.
https://ocw.mit.edu/courses/6-172-performance-engineering-of...
So not PowerBI then. Or really any BI tool.
My favourite example of not "fast" right now is any kind of Salesforce report. Not only are they slow but you can't make any changes to the criteria more often than once a minute. Massively changes your behaviour.
Fast is why, after decades doing high-level scripting, I'm now exploring lower-level languages that live closer to the metal...
Related https://github.com/kelseyhightower/nocode
Adding to this - that's why I insist all my students should learn touch-typing, for at least 10 minutes per lesson. It really changes how you interact with your computer, and how much touch typing quickly makes you able to type as fast as you can think changes your approach to automating things in a quick script or doing some bash-fu. A very underrated skill in todays world.
> students should learn touch-typing
I agree, but I wonder how not knowing how to spell would affect that. The highschool kids I work with, are not great spellers (nor do they have good handwriting).
Browse the HTML. This site looks hand-coded. The Google fonts and some light CSS are the only imported stuff. No javascript.
It's gorgeous
I was curious, so I checked, it is raw html. And yes it is beautiful.
https://github.com/juecd/juecd.github.io
Speed is an important usability consideration that gets disproportionate focus among many developers because it’s one of the few they can directly address with their standard professional toolkit. I think it’s a combo of a Hammer/Nail thing, and developers loving the challenge of code performance golf. (Though I never loved stuff like that, which is in part why I’m not a developer anymore.)
Figuring out the best way to present logically complex content, controls and state to users that don’t wrangle complexity for a living is difficult and specialized work, and for most users, it’s much more important than snappy click response.
Both of these things obviously exist on a spectrum and are certainly not mutually exclusive. (ILY McMaster-Carr) But projects rarely have enough time for either complete working features, or great thoughtful usability, and if you’re weighing the relative importance of these two factors, consider your audience, their goals, and their technical savvy before assuming good performance can make up for a suboptimal user workflow.
Thanks for enduring my indulgent rant.
> Rarely in software does anyone ask for “fast.”
That's because it's understood that things should work as quickly as possible, and not slowly on purpose (generally). No one asks that modern language is used in the UI as opposed to Sanskrit or heiroglyphs, because it's understood.
> Rarely in software does anyone ask for “fast.”
It is implicit, in the same way that in a modern car you expect electric windows and air-conditioning (yes, back in the day, those were premium extras)
Agree. One of my favorite tropes to product and leadership is that “performance is a feature”.
I got so tired of waiting for GitHub pages taking ~600ms to load (uncached), so decided to build my own Git hosting service with Go and HTMX.
I know this is completely different scale, but compare: [1] https://github.com/git/git [2] https://gitpatch.com/gitpatch/git-demo
And there is no page cache. Sub 100ms is just completely different experience.
Very nice. Also a plea. Don't animate the >. Or, don't wait for the animation to finish before showing the contents.
ah, interesting. It starts fetching tree items on mousedown (vs onclick) to load them faster, so > starts moving a bit too early.
> Fast is relative
I once used Notion at work and for personal note taking. I'd never felt it was "slow." Until later I moved my notes to Obsidian. Now when I have to use Notion at my job it feels sluggish.
Notion just seems to get worse and worse. I used to love it but now I find it infuriatingly slow.
Glad to hear Obsidian is better as I’ve been considering it as an alternative.
Obsidian's local first editing experience makes a huge difference to creativity and flow.
I've been working on making Obsidian real-time collaborative with the Relay [0] plugin. In combination with a few other plugins (and the core Bases plugin) you can build a pretty great Notion alternative.
I'm bullish on companies using Obsidian for knowledge management and AI driven workflows. It's pretty reasonable to build custom plugins for a specific vertical.
[0] https://relay.md
This is a great blog post. I have seen internal studies at software companies that demonstrate this, i.e. reducing UI latency encourages more software use by users. (Though a quick search suggests none are published.)
Finally, someone has thought about the importance of making things go faster!
Is the most pressing problem facing the world is that we are not doing enough things fast enough? Seems a bit off the mark, IMO.
This page (consisting of 693 words) took a full second to load for me because it had to import multiple fonts from Google (which also constitute over 70% of the page's size).
Do you mean finish loading?
Google Webfont loader is (usually) non blocking when done right, but the text should appear fine before
The page loaded instantly for me
Yep. I often choose LLM apps not because of how great the model is, but how snappy the UI feels. Similarly I might choose the more lightweight models because they’re faster.
Conversely, we have a whole generation of entry-level developers who think 250ms is "fast," when doing on-device processing work on computers that have dozens of cores.
I like fast but more and more I get slow web applications where every clicks comes with a delay.
Trading software by it's nature has to be fast, fast to display new information and fast to act on it per users intent.
Fast is dead. The only software that keeps getting faster are emulators to run legacy, bloat-free code.
If you want fast try booting your old DDR3 computer, that's fast!
"Fast signals simplicity"
Bookmarking this one
> But software that's fast changes behavior.
(Throw tomatoes now but) Torvalds said the same thing about Git in his Google talk.
What about, centered text?
Google talked about this for years.
Yes. The same insight periodically appears. Also, often it's done with high contrast text, which is great.
That's why we all code with voice now, because it's faster, right? Right?
Would someone please forward this article to the folks that work on Jira?
related: https://bdickason.com/posts/speed-is-the-killer-feature/
I'll take reliable over fast almost every time.
True, but not fast. More fun than fast.
Fast reading does not just enumerate examples.
Fast reading does not straw-man.
Fun conveys opportunity and emotion: "changing behavior", "signals simplicity", "fun". Fun creates an experience, a mode, and stickiness. It's good for marketing, but a drag on operations.
Fast is principles with methods that just work. "Got it."
Fast has a time-to-value of now.
Fast is transformative when it changes a background process requiring all the infrastructure of tracking contingencies to something that can just be done. It changes system-2 labor into system-1 activity -- like text reply vs email folders, authority vs discussion, or take-out vs. cooking.
When writers figure out how to monetize fast - how to get recurrent paying users (with out-of-band payment) just from delivering value - then we'll no longer be dragged through anecdotes and hand-waving and all the salience-stretching manipulations that tax our attention.
Imagine an AI paid by time to absorb and accept the answer instead of by the token.
Fast is better than fun -- assuming it's all good, of course :)
> Instant settle felt surprising in a world where bank transfers usually take days.
Yeah, that's not "a world" it's just the USA. Parts of the world - EU, UK etc have already moved on from that. Don't assume that the USA is leading edge in all things.
> Yeah, that's not "a world" it's just the USA.
"In a world" is a figure of speech which acknowledges the non-universality of the statement being made. And no it is not "just the USA". Canada and Mexico are similarly slow to adopt real-time payments.
It is wild to tell someone "don't assume" when your entire comment relies on your own incorrect assumption about what someone meant.
There is better commentary on the same basic point regarding SEPA / Faster Payments / FedNow and how the US lags world-leading practice in the other thread here: https://news.ycombinator.com/item?id=44738579
It's a bit more substantial, and less complaints about the semantics of the wording.
You’re not wrong. The US banks all suck. I’m willing to bet that every single one of them suck, though I’ve only tried a handful.
this would align well with the concept of Permacomputing
https://permacomputing.net/
Will apply this for the next interfaces that im going to build
Is it just me or is the premise of this the opposite of your work life as well? I have worked in the space of "fast" primarily and that is the main objective. Fast, iterate ... Don't be like "IT" (the slow team nobody can fire who never finishes anything).
Of course fast has downsides but it's interesting this pitch is here. Must have occurred many times in the past.
"Fast" was often labeled "tactical" (as opposed to "strategic" in institutions). At the time I remember thinking a lot about how delays plus uncertainty meant death (nothing gets done, or worse). Even though Fast is often at the cost of noise and error, there is some principle that it can still improve things if not "too far".
Anyone know deeper writings on this topic?
> Speed conquers all in martial arts.
Beautiful softwares are fast! Love the blog
This is such an important principle to me that I've spent a lot of effort developing tooling and mental models to help with. Biggest catalyst? Being on-call and being woken up at 3am when you're still waking up... in that state, you really( don't want things to go slowly. You just want to fix the damn thing and get back to sleep.
For example, looking up command flags within man pages is slooooow and becomes agonizingly frustrating when you're waking up and people are waiting for you so that they can also go back to sleep. But if you've spent the time to learn those flags beforehand, you'll be able to get back to sleep sooner.
Slow is smooth, smooth is fast.
Linear vs JIRA described in 1 word
One of these days I’m going to get around to writing a little bash script or something that will let me take a plain-ish text file and upload it into Jira via the API.
I should be able to create a Jira ticket in however long it takes me to type the acceptance criteria plus a second or two. Instead I’ve got slow loading pages, I’ve got spinners, I’ve got dropdowns populating asynchronously that steal focus from what I’m typing, I’ve got whatever I was typing then triggering god knows what shortcuts causing untold chaos.
For a system that is—at least how we use it at my job—a glorified todo list, it is infuriating. If I’m even remotely busy lately I just add “raise a ticket for x” to my actual todo list and do it some other time instead.
Anyone who uses LLMS should suck on my ballsack
Facebook is fast?
That article loses its credibility because of this, my thoughts too. Facebook and Instagram websites are among the worse offenders when it comes to "time-to-content" or whatever metric cool kids use these days. Maybe the apps are faster, but I'd rather avoid spyware on my pocket computers. Probably the author is running a $3k+ laptop and renews it every year?
Oh yeah, back in the late 80s we (for some finite and not so big values of "we") were counting MOS6502/6510 cycles to catch the electron beam on a display and turn on some nice/nasty viaual effects.
Tell me "fast" again!
"Fast" is just another optimisation goal in a spectrum. First make it correct, then make it good, then make it fast (is a reasonable rubric).
small (font)
[dead]
But the future is vibe coding and shipping fast even if we don’t understand the code the LLM wrote!! The only speed metric worth caring about is time to market! Just fucking ship! /s
[dead]
[dead]
> Rarely in software does anyone ask for “fast.”
Are you kidding me? My product owner and management ask me all the time to implement features "fast".
Not sure if this is sardonic obstinance... But assuming face-value - that's not what the statement is about.
I disagree with the statement too, as people definitely ask for UX / products to be "snappy", but this isn't about speed of development.
I remember the time they were cracking down because I had entered 90%+ of the tickets into the ticket system (the product manager didn't write tickets) and told me that "every ticket has to explain why it is good for the end user".
I put it in a ticket to speed up the 40 minutes build and was asked "How does this benefit the end user?" and I said "The end user would have had the product six months ago if the build was faster."
These days metrics are so ubiquitous that many internal back-end systems have SLAs for tail latencies as well.
Yeah, this was an attempt at humor. But it is quite easy to misunderstand the title.
[dead]
[dead]
[dead]
[flagged]
Ew.
Genuinely hard to read this and think little more than, "oh look, another justification for low quality software."
I think you misunderstood the use of "fast" in the article? They mean that the software should run fast, not be produced fast necessarily. In my experience software that truly runs fast is usually much higher quality.