The problem is knowing what to measure. There's another saying
"When a measure becomes a target, it ceases to be a good measure."
As an example from memory, there was a game dev company that celebrated they had maxed out the cores on the PS3. That didn't mean anything though, anyone can max out the cores by filing them with bad code. But hey, their "measurement" told them they had maxed out the machine
This can be a problem, but much less so because so often we're doing "easy mode" where we don't need a proxy. The "it ceases to be a good measure" is because you're measuring a proxy. You wanted to deliver happiness, you measured wealth because it was easier to measure but seemed correlated and now you've got rich miserable people, oops. But software engineers can often measure the actual thing they want to improve directly, not a proxy and so it cannot cease to be a good measure.
With a few caveats, though they do tend to get fixed over time. For example, frame rate. Higher frame rate is better, the end, right? Wellll...
Latency and hitching are annoying to measure, so for a long time, they were pretty much ignored. That has improved and hopefully will continue to improve. There is the bufferbloat initiative, gaming magazines take frame time histograms now, input devices and screens commonly have their latency measured. But latency is still under-measured - for GPUs / GPU drivers, for all software, for games and particularly for websites.
Yeah, frame stutter is definitely one of the cases where somebody may end up targeting a proxy and that saying about targets happens as expected. A game which typically hits 50-60fps but has occasional half second stutters may not fix the stutters if your proxy was "time to render 100 frames" and you throw out outliers - since every stutter will be an outlier.
That quote mostly applies to human organizations where the connection between outcome and metric is questionable. Or where incentives unexpectedly change behavior.
If your goal is fast software it can be measured quantively and you’re likely to improve the actual thing using those metrics.
The goal above was to write fast software. The developers made the mistake of seeing that they had saturated all the cores as "We did a good job of using the entire machine" = "our code is fast". They had a measurement and misinterpreted what it meant.
They didn't measure memory, they measured how busy each processing unit was. It's like going into Activity Monitor, Tops, Task Manager, seeing all CPUs at 100% from your app and thinking "We've reach peak perf by utilizing all the processing power"
People still do that today. They run some LLM or gen AI type app. See all the numbers reach high percentages, and wrongly think "this app is using all of my machine's potential"
Casey generally, across all his material, advocates for non-pessimisation. Measurement takes too long to apply it to your entire program. He advocates for thinking about how much work the computer should actually have to do, then not making it do much more than that, at all times. This means avoiding serial dependency chains on the network, and huge towers of abstractions, and redundant work. He allows for writing lazy slow code as an intentional tradeoff that you may revise later if it becomes a bottleneck. He does not allow for inherently slow architecture.
Sure, but there are performance issues no profiler will catch in a straightforward flamegraph reading.
Some examples:
1. Your hottest loop is spilling registers which only shows up as non-local cache thrashing (i.e. some other random code becomes slow) or randomly slow instructions i.e. "why is this xorps to initialise this int suddenly slow" due to pipeline stalls
2. Your code stops fitting into cache due to the code bloat, there's no one method which is slow, everything is slowed down by a percentage factor
3. A lot of useless work being done like temporary strings being copied everywhere
4. Your code is "I/O bound" because all the data you're accessing is scattered all across memory, leading to completely predictable TLB stalls
It's very easy to make a large program, quite a bit harder to make a small one...
In other videos Casey argues against the profile–fix–repeat workflow (I’m not saying that you necessarily meant this by measuring), instead arguing for estimating the theoretical maximum, then trying to get close enough to it. His argument is that the former might push you towards a local minimum without realising that you could do much better
When "Estimating the theoretical maximum" you're going to bring your assumptions to that estimate and so you're equally likely to get stuck in some local optimal point because you didn't see what else was possible, so that doesn't persuade me much. Worse, now it's a local optimal which might be entirely in your head.
There is some space for this "Estimate the theoretical maximum" as a high level insight, if the software needs to do a thing which your estimate says is impossible that's important to address up front but I think for practical software engineering you're much more likely to need profile-fix-repeat
Actually measuring is crucial and an estimate is not a measurement. I think one of the reasons many in the Handmade Community don't like measuring is that it too often ruins their "estimate" of how the crap they've written is achieving a "theoretical maximum" in favour of a boring fact that it's much worse than alternatives.
Usually the ideas it that the theoretical maximum is not a local optima though, but some ideal global optima which you know you realistically cannot reach.
That is you know the data is some size, and memory throughput is some rate, and clock cycles is some rate etc...
You are entirely correct about the line of thinking if your assumptions are down a different line of thinking such as algorithmic estimates though, where you might miss some better way of doing things.
I've always used this method of working and can stand by it. For instance let's say you are working on a high-speed real-time image processing system. If you know that each image is 1080p for instance, that's 2 million pixels, and we will have 3 bytes per pixel for colour, then that's like 6MB per image (without compression). If you have 25 GB/s of RAM bandwidth, then there is a hard limit of ~4 thousand frames per second if you aren't even doing any processing. Therefore if you strip out your processing and are only getting say 400 frames per second, you know something is going wrong.
This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.
Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.
He works in the engine/tool side of things. He worked on some widely used libraries, mainly Bink 2 (video codec) and Granny 3D (3D animation) used in a ton of shipped games.
Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed.
What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professional success to a large extent.
He did work on the video games Dungeon Siege and The Witness afaik, but that's not what he is known for.
He mostly evangelizes non-pessimal software. He advocates that your program should only be a small factor like 3x slower than the hypothetical optimum - instead of 10000x slower as today's software often is. He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger and found the former much faster when performing the same tasks.
I have recently gotten a 45x on a shitty vibe coded Python project by using mypyc (2x), replacing datastructures with more CPU-friendly alternatives (15x) and using some smarter heuristics rather than just brute force on top of that (45x total).
And I never left Python, the slowest language around.
AI is only going to make the problem worse unless you know what to look for.
> He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same project file and code files.
Yes, it really shouldn’t, and so Casey goes to great and careful lengths to fully evidence these results. This is a nuance that’s easy to miss in evangelizing “Casey Muratori content” to others. It’s easy to gloss “abjectly unacceptable performance” as “bad performance”.
And people still come out of the woodwork with a parade of excuses, and sometimes he addresses those too. But it's no wonder that he gets a bit brisk or blunt with people, and turns off others who haven't been following along.
When did you start using computers? I'm getting older now, and some people weren't alive when I first used a computer.
It's because the older programming approach was to just tell the computer how to do the thing - and the modern approach is to write a framework inside which you write a framework inside which you write an inefficient version of the thing because it's constrained to the tools available in the framework stack.
Old-school implementation of "scroll up": copy pixels then redraw the pixels at the bottom.
New-school implementation of "scroll up": delete virtualized rows from the beginning of a DOM table and add more to the end. Change the height properties on different parts of the scrollbar. Relayout the whole DOM, several times if you're not careful. Redraw the whole screen.
"Highly successful middleware provider back in the day" is an understatement.
Bink was the cutscene video codec for a long time and it's still the most popular option by far. Kraken compression is so good Sony worked with AMD to make a hardware decoder for the PS5 and paid for a general license that lets games use it for free. They are probably stronger than ever in terms of games using their tech and collected license fees.
> They are probably stronger than ever in terms of games using their tech and collected license fees.
True, though they've been acquired by Epic since 2021. They keep the RAD Game Tools branding, but aren't their own separate company anymore.
Oodle/Kraken is mostly the work of Charles Bloom and Fabian Giesen, a couple of other "legendary game programmers" at RAD, but who aren't quite as visibly prominent as Casey has been in the modern software developer mediasphere.
I remember using it to encode some videos for a school presentation. I think I needed to make it fit into a CD and play-on-double-click and Bink was the easiest tool to do it in.
Honest question, but what is the benefit of Bink over standard codecs like H.264/265 or AV1? Specially nowadays that every GPU provides hardware-accelerated video decoding...
I get the auto-transcript with yt-dlp then ask a cheap LLM like DeepSeek to clean it up.
Though lately I've been uploading the audio to AssemblyAI, I somehow still haven't used up my credits after several years lol
At one point I built a system that would summarize the transcript and I'd be able to ask questions about it, but Gemini can do that natively now so I usually just use that.
I’ve found this too but I think audiobooks still have a place, they just can’t something you rely on being able to perfectly understand. A second book on the same topic or something in a topic loosely related but interesting. Or fiction to help stay awake on long road trips.
It's likely the same for me, but I tend to relisten to audiobooks I like, sometimes dozens of times. I have a hard time focusing on physical books, and I've probably only re-read a handful of them, so the net effect is that I take in more with a good audiobook.
I used read a lot of books when I was younger, then slowly stopped, and found getting back to reading quite hard as well. Armed with the knowledge that I used to be able to do this, I just forced myself to. And after a while, I found I had no trouble committing any more.
I think it really is a matter of distraction. When I was using public transit a lot, I managed to get through books really quickly by substituting them for my phone. And there was a period where I had no phone for a few months in a new city, and I just read constantly. Even outside while walking. I do the same on my phone, after all.
It's worth the listen if you're even mildly interested in the history of computer science. He's a great presenter. I guess at some point you do have to prioritize how to spend your time, though.
Casey mentions that at some point one of these great minds were upset that it was so difficult to write programs because they didn't have things like keyboards or screens. One of them even brings up exciting new developments in electronic typewriters that could be used to improve their workflows.
It is quite long, but I thought it was worth it if you can find the time. Short of that I think just reading the Knuth article the quote is from might bring similar insights.
It’s on YouTube, pull the transcript and format it with an LLM. If there’s no transcript, there’s Whisper. All of this can be done with local models too.
Audio transcription is nowhere near the same as a properly written piece of text. Videos are simply a different format, and thus a lot of the communication is held by the fact that there's visual cues to go by. If one were to write an article about the same, you'd use much denser language as well as references/links around the topic. Maybe even restructure the whole thing to communicate it better through text.
It is something you can maybe whip up with the help of an LLM but then you're left wondering whether it is actually communicating what the video intended to begin with, as you wouldn't be as knowledgeable about the topic, one wouldn't be able to spot the parts where an LLM interpreted something horribly and thus reaching the wrong conclusions.
For all of the above, I do not consider audio transcript to be of any help when one prefers written content. It is useful for translation or people with hearing issues, but both of those receive help of the visual parts to convey the topic.
The last hour is a Q&A. I don't know if that changes your perception of how watchable it is.
It's also a little fluffy. It's basically the history of how the book Structured Programming came about, because it's that book that essentially caused Knuth to write an article that contained the quote.
A lot of it is fairly interesting but it also highlights a big problem I do have with Muratori. He generalizes from self. He didn't fully understand or appreciate the quote about premature optimization, so no one did. And even though he's been told what it actually means, and was probably pointed to the full quote, he would stick on his interpretation. It's likely someone he views as "higher", like Jon Blow, challenged him and then he took the time to actually look at it.
"He didn't fully understand or appreciate the quote about premature optimization, so no one did."
He ain't wrong though.... most people definitely don't get the jive for sure.
Knuth was talking about a massively different kind of optimisation than what we do today yet people keep continuing to parrot the 97% figure uncritically like as it was some gospel. [0]
The fact that some people misunderstand doesn’t mean everyone does. Or even most.
It often feels like “most people” gets trotted out when there’s no real data on the subject. In a lot of ways you’re committing the same error you’re accusing this random blogger of: believing something uncritically without actually trying to verify the claim.
Casey isn’t famous for his contributions to computer science or even game development, he’s famous for his streaming and talks. And to that, I’ll point out Jason “Thor” “PirateSoftware” Hall was also a popular devfluencer until he got on the nerves of too many people and they started investigating his claims. So the fact that Muratori is notable doesn’t hold weight.
I think Casey is currently the most informed person to make a series of books or articles summarizing the history of SW Engineering, all the lessons learned and forgotten, and all the good stuff that was published and still hasn't gained traction in the practice
Ehh I love Casey and have learned a ton by watching how he thinks about things in his handmade hero series, but he is fairly narrow minded in his views of dev. Not that theres anything wrong with that, for the kinds of dev he does his approach is very good. But its not generalizable.
I suppose it is a matter of what one works on, but that has been consistent in my career.
I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.
It’s not a coincidence that Casey and other high profile performance minded people are in game dev. Thats a field where performance is important (or at least a consideration). In web dev or regular enterprise app dev it’s simply not a consideration that needs to be made most of the time.
How is this relevant? I didn't say he should make a book about his teachings about SWE, I said he could compile a comprehensive review of the foundational literature of compsci
You think there aren't other people equally or more qualified? I mean Casey may be the most visible person with those qualifications - but lack of visibility doesn't imply lack of competence, plenty of brilliant people work in the background..
Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science and the ideas that have not yet come to fruition despite being extremely old
> Feel free to point to anyone doing these deep dives
Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food.
I used to spend a lot of time watching crap like lex and primagen before it became obvious that these kinds of information channels are not meaningfully enriching despite sounding like they should be to a casual observer.
You are making many assumptions. First of all, he is doing the deep dives by researching all those articles, and of course the resulting presentation will be very superficial. The point is exactly to publish a book to allow the reader to partake in the deep dive.
Secondly, nobody said anything about applying that stuff to your daily work.
My one data point is that Casey’s handmade hero series, and his immediate mode gui video from way back in 2005, are what introduced me and some friends to an entirely new way to build graphical user interfaces, and I do feel a great appreciation for that. Guys like Ryan Fleury (of RadDbg) and Vjekoslav Krajacic of Filepilot similarly credit Casey with their “radicalization” :)
To your point though, it was less about specific technical knowledge conveyed by these videos and more about him evangelizing a high level approach that many folks otherwise wouldn’t have considered
I want more things like that old hand made hero to exist in the world, but, from an interview with Casey himself, it doesn’t pay well enough to justify. Someone with the chops to put that together is in a position to be doing something much better incentivized.
> Open source is the very worst thing currently going on because it is so incredibly exploitative, it's far more exploitative than any actual company is of the workers who work at the company.
> Even the people who are getting paid in open source are getting massively underpaid to do it compared to how much the people who are using their code are making, it's nothing compared to the power that is accreted by the people who have co-opted that work thanks to the open source model. And then mark zuckerberg gets to define how the internet works despite having paid for almost none of the software that his company actually needed to make that work.
> It's like feudalism or serfdom, these people did the work and got nothing for it. It's like you took the worst aspects of capitalism for workers and the worst aspects of socialism for workers and put them together, that's open source. You get no power and you get no money.
> It's exploitative whether the people chose to be exploited, just because someone chooses to let you exploit them does not mean that you didn't exploit them. And for the record that's how most exploitation works; convincing people to do something that turns out to be very bad for them and very good for you, and that's exactly what the open source movement has turned out to be.
> I really don't see the "we post stuff on github under a gpl2 or lgpl or apache or mit license", all that is to me now is just exploitation. You can say that there's solutions but until someone demonstrates that those solutions work, it's the standard "real communism has never been tried" argument. AGPL is the only thing that I've seen so far that's an attempt to fix these fundamentally unfair compensation practices.
This is the first I've heard of these critiques from him, and as someone who loves open source/Linux, and belives it makes the world better in many ways, I think they're pretty valid. The model has major issues in at least two distinct ways:
1. Not paying for the labor corporations exploit. GPL is better here, but still imperfect. MIT/BSD is awful here. It wouldn't matter in an ideal post-scarcity society, but we don't live in that yet, so it does matter. Until post-scarcity, a better model would route revenue from exploitative capitalist uses back to the creators and/or their desired sinks.
2. The open source bait-and-switch - startups using open source to get users and then pulling up the ladder and going closed source and monopolistic once they have achieved scale to enforce/ achieve lock in.
Usually when I talk to very staunch FOSS zealots they're bewildered that someone would care what a corporation does with their code... at least as long as the license terms are adhered to.
In fact they don't seem to care about money at all, often believing all corporations/capitalism are bad, and that they and everyone else should just be poor and live in the woods or something.
Prime is an entertainer first and foremost. He talks with confidence, even when he doesn’t know what he’s talking about - which is very often.
Casey is far more measured, careful and accurate. Casey feels like an engineering educator first, who happens to make YouTube videos. I don’t always agree with Casey’s technical opinions, but he seems like a thoughtful guy who thinks things through.
Yeah I was a sense that some people would be more into serious technical explorations and not just distanced review of the past (even though it can bring some knowledge).
>Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science
I skimmed through the video because I don't have two hours but there's no lost knowledge in it, he's going over well known papers from Dijkstra, Hoare or Knuth. The paper he bases most of the talk around Knuth's Structured Programming with go to Statements is his most often cited work, there's a very high chance you'll encounter that early in any undergrad course. So the answer to your question is, pretty much at any local uni with a CS course.
The well known papers are not what the talk is about though. The talk is titled "The root of the root..." specifically to go over the specific and incredibly/almost impossible to find citations those well known papers used and built upon to see what historical insights that might have been lost went into how those papers are now interpreted (or as the video argues, misinterpreted).
Pretty much any book or long paper that decides to take a historical turn is going to be at least as good if not better than these talks. There are a lot of historical resources out there that go into different parts of "computing history" more generally. I don't know what would meet your criteria for computer science or software engineering more narrowly. To me they are all very interconnected. I couldn't say whether it'd be more important to have a nice presentation that includes Babbage and his machines vs. a neat presentation that covers Codd's work going directly into Chamberlin and Boyce's work on System R. A historical presentation has to decide what it includes and excludes. In recent times I've enjoyed Fabien Sanglard and his work on the histories of Wolfenstein 3D, Doom, the hardware environments behind them (development and deployment), and the CP-System. Lots of "lost" technical knowledge in them. Of course the earlier and higher level Masters of Doom book contains a lot of neat history as well, though less technical. The HOPL (History of Programming Language) papers are always insightful and contain a lot more "plain" computer science, though of course with a focus on programming language things. Richard Gabriel could write a lot more of history than he already has; here's one of his papers that (among other things) details a history of mixins in object oriented languages, and how they were "rediscovered" poorly in a way that obscured their actual historical nature, demonstrating an idea of incommensurability. https://dreamsongs.com/Files/Incommensurability.pdf
I should also add that even interviews are valuable. Coders at Work is fantastic at that and drawing out technical opinions and reasoning; notably the subjects interviewed don't all agree and have sometimes drastically different work styles and preferences.
He's entertaining and well spoken. Love it. Not sure the book medium would be the best avenue. My own sweet spot is presentations, live interviews and meetings. I can't write for sh*t, even if I tried. I know.
I feel like the comments that are giving you pushback haven't actually listened to Casey before. I agree with you, while opinionated his perspective is very pragmatic and misunderstood. He's done such a great job giving his experience out to the broader world too.
This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally.
While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say, he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and then talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.
Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) A "complete" history as the top comment suggests would be better as a multi-author endeavor, if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.
Yeah. Casey is just some guy who’s good at software and YouTube. I’ve worked with dozens of people at his level technically. But very few with his interest and skill at making videos.
It’s a pity there’s not more people like him. I’ve met some incredibly smart people in the FP world. I wish more of them made approachable YouTube videos explaining what they know. I recently learned about “Safe Haskell” which, if adapted to rust and other languages, could solve a lot of the security problems with npm and cargo. But nobody knows about it! We need FP Casey.
Safe Haskell is just a worst version of Rust's unsafe. What it actually does is equivalent to Rust's #![forbid(unsafe_code)] which immediately lead to a question: so Haskell has unsafe, just like Rust? And of course it does. Any practical systems language has unsafe in one form or another, not only for FFI but also for performance, Rust is just honest about it.
There's two reasons Safe Haskell is substantially worse than what Rust does. Safe Haskell works by annotating code that is safe, but that's entirely backwards. We need to annotate unsafe code, and explain in plain English exactly why it is okay in that particular instance (of course it would be better to explain in code, like, give a formal proof that is checked by the compiler, but then it isn't unsafe anymore!). Safe Haskell answer for that is to annotate good unsafe code as trustworthy, but that doesn't work because it doesn't goes in detail on why the code is trustworthy (to do so you really need to go into the details, you can't handwave it). It's the // SAFETY comments that are at the heart of Rust's unsafe, carefully explaining safety invariants that must be kept (specially important if we are modifying code), not unsafe { } blocks.
The second reason is much simpler. It's optional, and approximately nobody uses Safe Haskell or cares about it. If people used it we would have something to improve upon. So Rust achievement here is mostly sociological, it's a community of programmers that care about safety. Which is good given that a Rust program typically have much more unsafe code than a Haskell program.
The thing I really want is a language or environment with no implicit access rights. So, if I call add(a, b) then the add function doesn’t have implicit access to the filesystem, network or global variables in other parts of the program. If you want to give a function access to a subdirectory, you should pass a handle to that subdirectory as an argument and use openat() or equivalent.
This would guarantee - at a language level - that leftpad or log4j can’t root my computer.
Safe rust doesn’t give this guarantee. Safe code can still make arbitrary syscalls. Safe rust can convert a path string to a File. Or open arbitrary network sockets. Rust also doesn't have a way to import a crate but forbid the use of any unsafe blocks.
I want to be able to use 3rd party code from cargo without getting hacked. Right now rust does not keep me safe from these supply chain attacks.
I don’t know enough about safe Haskell to know how close it tacks to this. But that’s what I want.
I think nextaccountic is not technically fully correct, but he/she is at least correct in the most important part: Safe Haskell is not really practical.
But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations)
How does this compare to Spritely Goblins? I had a good chat with Christine about it at a conference. She said "Ah, you've been infected with the capabilities virus too. My condolences."
Interesting, I have not heard of Spritely Goblins! But neither Bluefin nor effectful could be described as distributed capability systems/effect systems, so I don't think they're comparable.
On infection, I think it's a bit like being infected by mitochondria :)
> The thing I really want is a language or environment with no implicit access rights
I don't think you'll find anything like that from a General Purpose Language, so you probably want something like WUFFS [Wrangling Untrusted File Formats Safely].
It is kinda funny that some world-renowed people who invented genius algorithms like quicksort and graph shortest-path were mulling over "hey would be nice if we kept related data together in a struct" and some people were raging over it saying "why you want to change how I work?"
Casey points out that many of the lessons they came to were so obvious that it just became how it is done that no one even remembers it was done in any other way. In the talk the laments it makes it really hard to track down who originally came up with these ideas.
His dismissal of the argument Knuth makes regarding the hot loops could have been explored a bit better. I found it weird he didn’t mention the difference of types of programs of then vs now. Even today, in scientific code it is still absolutely the case a lot of the time that a huge chunk of the runtime comes from a single very very hot loop. It might be hidden in a library, but it’s there.
Instead he focuses only on “program size”.
Knuth samples where very small FORTRAN programs (compared to today’s standards). Today’s program are bigger but the fundamental number crunching primitive of “let’s compute stuff in a loop” remains. It’s just buried under a pile of extra cruft (data loading, parallelism, dispatching etc).
Now we just deal with a lot more programs that are of a whole different class compared to what they where doing with computers in the 70s. We have much more I/O involved. And hot loops don’t like being I/O bound.
Realizing I didn't quite answer your question about types of programs then and now. In the Q&A, they do discuss what types of (Fortran only) programs were measured in the study, and there is some speculation, but unfortunately the documentary record wasn't particularly solid.
Being I/O bound is usually a result of bad engineering practices though.
If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare, or more likely that your code is so unoptimised that barely any computation gets carried out while your code is waiting on memory/disk/network.
"I can't do anything because my program is I/O-bound" is more of an excuse / mental justification of why your program is slow instead of an honest reason for so.
ETL processes are heavily I/O bound, especially when you're trying to shuttle data from one enterprise system to another enterprise system. It's also common when the culture of data exchange from the regulator all the way down to the companies doing the actual work is batch processing where large amounts of data are shared once a day as opposed to real time. Excel spreadsheets are the norm, not the exception. Requests for data to be sent over via XML or JSON are mainly because my employer wanted to make it easier to process the data ourselves, but the regulators actually expect spreadsheets.
Most of the stuff I work on is almost exclusively network I/O bound. I wouldn't say it's a _result_ of bad engineering practices, though. One group decided on a particular system that's also public-facing, and the group I actually support prefers a more internal-facing system. It also doesn't help that the budgets for both projects are completely separate and firewalled from each other by law. Growth opportunities don't apply here because I deal with a captive market with legally-forced customers.
> I/O is inherently very slow compared to computation
This isn't really true anymore. IO has bad latency, but modern SSD bandwidth is ~5-15GB/s. If your program is IO latency bound and processing less that 5GB/s you aren't IO bound, you aren't hiding your latency well enough.
> I/O is inherently very slow compared to computation.
Not anymore, no. Your SSD, before caching, does gigabytes per second of sequential reads. For any bytewise processing, except the most trivial of tasks, you’ll struggle to get above a few hundred megabytes per second with native scalar code. To actually keep up with a modern SSD, you’re virtually guaranteed to need handwritten SIMD, minimize the number of syscalls with techniques like io_uring, or possibly be smart about distributing tasks across cores without ruining the access pattern.
For instance, simdjson is famously fast but I don’t believe it can keep up with say a Samsung 990 PRO. And I know of no Unicode normalizer that would be able to do a gigabyte per second on general inputs (not ASCII, not Latin-1) simply because the RAM latency for dependent lookup table accesses is absolute murder.
Your analysis is correct if and only if the data is on the same machine as the calculations. If the data comes from another machine, it comes at network speed. If it comes from the internet, it comes at non-local network speed. That's very different from SSD speed.
No, you're comparing apples and oranges. All an SSD sequential read is doing is copying data from one place to another. So you should be comparing SSD bandwidth to memory bandwidth, not SSD bandwidth to (time it takes to execute some arbitrary algorithm). Or you should be comparing SSD bandwidth when performing millions of tiny random non-sequential reads and writes, to the algorithm time.
Muratori et al. like comparing processing speeds to (single-core) memory bandwidth and that’s a reasonable upper bound, but generally it seems to me that, unless you operate on huge elements and don’t do very much with them, you won’t get within an order of magnitude of it. Even if you think about RAM exclusively, the headline numbers are for sequential reads and things will slow down dramatically if you actually perform random accesses (IIRC, DDR5 is about as slow as DDR4 there in terms of physical time units, so much slower in terms of bus cycles). Meanwhile, in a real situation, you’re going to be bound by compute long before that.
And I think you’re being unfair labelling my couple of examples “some arbitrary algorithm[s]”: my choice was indeed arbitrary, but it’s also immaterial. The general setup would be that you’re processing elements in a loop and that your iterations are serialized (as they usually more or less are before you get around to optimization). A loop body of even three lines of C is likely to have a latency of 5–10 cycles or so, and you’re running on a core clocked somewhere from 5 GHz (desktop) to half that (server). So the best you should expect is ~500 MB/s if your elements are bytes, ~2 GB/s if they’re 32-bit integers, etc. For very simple tasks (that are also somehow not susceptible to vectorization), it is possible to not lose this order of magnitude and get down to almost 1 cycle/element in scalar code, but that requires heroic effort[1].
> If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare
This is backwards. I bet that by count, many more programs are written in domains where they're necessarily IO bound than the inverse. Anything that uses the network for its core functionality, anything reliant on a datasource whose aggregate contents are O(memory)+ size, or anything reliant on slow peripherals (lots of embedded software) are in this class.
Scientific simulations, HFT algorithms, video games, LLMs, etc.--the stuff in the other class--aren't inconsequential, but they're dwarfed in number by the class of software that spends 99+% of its time waiting for IO. Hell, entire programming languages (node.js) have been created in response to that proportion.
That’s completely backwards by orders of magnitude. Modern CPUs outrun L1 cache speed by a lot, L1 cache speed is on order of 1000-5000 GB/s, a GB/s is real bits used, is 8x of Gbps, and network speeds include significant overhead bits for frame packing and other data unused for the actual payloads.
You're not wrong in that there are some programs that could be doing more work in CPU/memory while waiting for IO, but those, too, are dwarfed by the number of programs that can't really do anything meaningful until IO completes. Anything that RPCs or IPCs data is generally going to be waiting for a complete RPC IO to finish before doing compute (and even the most granular RPC protocols tend to communicate in pretty big, slow chunks to maximize throughput). Lots of software waiting on local hardware (e.g. storage) is similarly doing IOs in pretty big pieces--maybe page-sized, or disk-block-sized, or file-sized--and can't do much meaningful CPU work until that's done. In embedded, it often behooves programs to get as much IO-sourced data read or written as is possible with available resources before switching back to CPU work--doing this increases throughput on slow hardware, and can also improve power efficiency.
Latency, throughput, power, hardware cost--those often trade off, and there's no free lunch.
The computers at the time had very little ram. The IBM System/360 didn’t get 1MB until 1968. I suspect a lot of programs were I/O bound just to be able to work at all. Most modern engineers cannot conceive of doing anything useful with 64KB and I think it’s a mistake to project modern practices 50 years into the past.
Plenty of scientific simulations end up being IO or communications bound when at scale (e.g. 30k CPU cores). Can hide latency to a certain degree but basically any algorithm that uses timestepping must halt at some point to allow data to flow around the nodes, or to dump data to disk for visualisation or checkpointing.
In saying that there are some novel and very clever algorithms that continue on without seemingly necessary boundary data, that then self correct when the data comes through, thus completely hiding the latency at the cost (in both accuracy and time) of running a correction process.
I took notice when he breaks down the ethics of gen ai as it pertains to online theft, that AI broke the natural order of putting content online where you'd trade exposure for use https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244
He tracks down where the statement "Premature optimization is the root of all evil" actually comes from, and whether the assumptions set out in the text where it was published still hold.
It doesn't really contain anything new or earthshattering, but if you find diving into the history of programming as a discipline interesting, it might be for you.
I would recommend it to anyone who liked the rambling style of "The big OOPs", but imo that one was better. I still liked it.
What I don't understand with both Muratori/Blow is that they seem to be incredulous that someone wouldn't just make software high quality and fast for the sake of it
Like they can't comprehend the fact that these things only happen if there is an incentive for it
I think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a game
They are so used to working in games that they take it for granted that the business incentive for performance exists
As someone who has worked in both AAA games and big tech it just comes across as a bit naive to me
I think there could be a version of our industry with people doing better work. And it’s worthwhile to study why we don’t have that industry.
Yes it’s incentives - but why these incentives exist and not others is an interesting question to study.
In the 2010s we pushed everyone to learn how to code and maybe lost some of our higher standards. Maybe we’re doing that now with AI?
Maybe broader social and economic incentives have had a lot of short term thinking of late? It’s hard to organize society or a company to go in one direction very long before incentives completely change everything. Who knows, maybe that’s a feature, not a bug.
It’s worth asking though why we have this software industry and not another one. I’m not convinced it’s for legitimate reasons.
I think the thesis would be there's a colossal structural/market failure in software. This because of many degrees of freedom, consumer ignorance, network effects and such. Compare this to physical things. The difference between the absolutely shoddiest couch sellable and the practically best one is tiny, compared to the difference between the worst software you could impose on the market and what could be achieved by competent engineers if we somehow removed the wrong incentives from capital and bureaucracy. With most software most people use, we are near the bottom of this range. I don't know if I fully buy that, even if we completely ignore whether removing these incentives is at all realistic. But would also say there's something there.
Then we can talk about how we all pay the increased cost in energy and materials, and so forth.
The fallacy is assuming it takes more work and effort to get good performance. When what’s really lacking is clarity about the problem and solution.
Optimizing code for max performance does take work. But just not doing incredibly dumb things and writing simple programs just takes education (and re-education).
I can’t count how many times I’ve replaced a distributed system with for loop.
You are assuming a greenfield scenario, in large brownfield projects it is quite easy to degrade performance by innocent changes. That is usually when the perf goes to trash.
It takes a lot more work to keep performance good in a large project than just letting it degrade.
This is a moot point. If you aren’t willing to change the system (have no business reason to) then you can’t implement or benefit from any new paradigms or advice and are necessarily bound by proper decisions.
I mean, it’s a thing in pretty much all lower level software that you want it to be fast. I guarantee you postgres and redis are trying to optimize the software to the cycle, because wasted cycles are wasted for all their users.
Setting aside incentives – because I think that's very fair to push back on, we should strive for better craft...
I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.
He's essentially never had to deal with distributed systems, or anything that allows multiple users to use the same system, with all the performance and anti-abuse issues that come with that.
His opinions about game development are insightful, and his thoughts on craft can be quite inspiring, but I think he could benefit from a stint on a (good) big tech server team to see some of the things he's currently missing.
171 comments
[ 0.16 ms ] story [ 46.3 ms ] thread(to be clear, I'm a big fan of Casey)
The problem is knowing what to measure. There's another saying
"When a measure becomes a target, it ceases to be a good measure."
As an example from memory, there was a game dev company that celebrated they had maxed out the cores on the PS3. That didn't mean anything though, anyone can max out the cores by filing them with bad code. But hey, their "measurement" told them they had maxed out the machine
This can be a problem, but much less so because so often we're doing "easy mode" where we don't need a proxy. The "it ceases to be a good measure" is because you're measuring a proxy. You wanted to deliver happiness, you measured wealth because it was easier to measure but seemed correlated and now you've got rich miserable people, oops. But software engineers can often measure the actual thing they want to improve directly, not a proxy and so it cannot cease to be a good measure.
Latency and hitching are annoying to measure, so for a long time, they were pretty much ignored. That has improved and hopefully will continue to improve. There is the bufferbloat initiative, gaming magazines take frame time histograms now, input devices and screens commonly have their latency measured. But latency is still under-measured - for GPUs / GPU drivers, for all software, for games and particularly for websites.
If your goal is fast software it can be measured quantively and you’re likely to improve the actual thing using those metrics.
Why not measure performance for which there are many good metrics.
People still do that today. They run some LLM or gen AI type app. See all the numbers reach high percentages, and wrongly think "this app is using all of my machine's potential"
1. Your hottest loop is spilling registers which only shows up as non-local cache thrashing (i.e. some other random code becomes slow) or randomly slow instructions i.e. "why is this xorps to initialise this int suddenly slow" due to pipeline stalls
2. Your code stops fitting into cache due to the code bloat, there's no one method which is slow, everything is slowed down by a percentage factor
3. A lot of useless work being done like temporary strings being copied everywhere
4. Your code is "I/O bound" because all the data you're accessing is scattered all across memory, leading to completely predictable TLB stalls
It's very easy to make a large program, quite a bit harder to make a small one...
There is some space for this "Estimate the theoretical maximum" as a high level insight, if the software needs to do a thing which your estimate says is impossible that's important to address up front but I think for practical software engineering you're much more likely to need profile-fix-repeat
Actually measuring is crucial and an estimate is not a measurement. I think one of the reasons many in the Handmade Community don't like measuring is that it too often ruins their "estimate" of how the crap they've written is achieving a "theoretical maximum" in favour of a boring fact that it's much worse than alternatives.
That is you know the data is some size, and memory throughput is some rate, and clock cycles is some rate etc...
You are entirely correct about the line of thinking if your assumptions are down a different line of thinking such as algorithmic estimates though, where you might miss some better way of doing things.
This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.
Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.
Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed.
What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professional success to a large extent.
He did work on the video games Dungeon Siege and The Witness afaik, but that's not what he is known for.
And I never left Python, the slowest language around.
AI is only going to make the problem worse unless you know what to look for.
this shouldn't be right, wtf
When did you start using computers? I'm getting older now, and some people weren't alive when I first used a computer.
It's because the older programming approach was to just tell the computer how to do the thing - and the modern approach is to write a framework inside which you write a framework inside which you write an inefficient version of the thing because it's constrained to the tools available in the framework stack.
Old-school implementation of "scroll up": copy pixels then redraw the pixels at the bottom.
New-school implementation of "scroll up": delete virtualized rows from the beginning of a DOM table and add more to the end. Change the height properties on different parts of the scrollbar. Relayout the whole DOM, several times if you're not careful. Redraw the whole screen.
Also I learned to program in Turbo C and Turbo Pascal with its debugger and nothing comes faster (at least nothing single threaded)
Bink was the cutscene video codec for a long time and it's still the most popular option by far. Kraken compression is so good Sony worked with AMD to make a hardware decoder for the PS5 and paid for a general license that lets games use it for free. They are probably stronger than ever in terms of games using their tech and collected license fees.
True, though they've been acquired by Epic since 2021. They keep the RAD Game Tools branding, but aren't their own separate company anymore.
Oodle/Kraken is mostly the work of Charles Bloom and Fabian Giesen, a couple of other "legendary game programmers" at RAD, but who aren't quite as visibly prominent as Casey has been in the modern software developer mediasphere.
I don’t know the extent to which he contributed beyond that, but he is therefore by some reasonable definition _a_ game developer.
[1] the-witness.net/news/author/casey/
I would very much prefer something written down, so I could absorb this at my own pace. I know, gift horse, but still.
Though lately I've been uploading the audio to AssemblyAI, I somehow still haven't used up my credits after several years lol
At one point I built a system that would summarize the transcript and I'd be able to ask questions about it, but Gemini can do that natively now so I usually just use that.
I used to do manual labor and I would work my way through like eight hours of audiobooks per day.
I would like to learn to focus... (https://youtu.be/1IRn8BN3Qhw?t=331)
I used read a lot of books when I was younger, then slowly stopped, and found getting back to reading quite hard as well. Armed with the knowledge that I used to be able to do this, I just forced myself to. And after a while, I found I had no trouble committing any more.
It is something you can maybe whip up with the help of an LLM but then you're left wondering whether it is actually communicating what the video intended to begin with, as you wouldn't be as knowledgeable about the topic, one wouldn't be able to spot the parts where an LLM interpreted something horribly and thus reaching the wrong conclusions.
For all of the above, I do not consider audio transcript to be of any help when one prefers written content. It is useful for translation or people with hearing issues, but both of those receive help of the visual parts to convey the topic.
https://rentry.co/2ttr46r9
It's also a little fluffy. It's basically the history of how the book Structured Programming came about, because it's that book that essentially caused Knuth to write an article that contained the quote.
A lot of it is fairly interesting but it also highlights a big problem I do have with Muratori. He generalizes from self. He didn't fully understand or appreciate the quote about premature optimization, so no one did. And even though he's been told what it actually means, and was probably pointed to the full quote, he would stick on his interpretation. It's likely someone he views as "higher", like Jon Blow, challenged him and then he took the time to actually look at it.
He ain't wrong though.... most people definitely don't get the jive for sure. Knuth was talking about a massively different kind of optimisation than what we do today yet people keep continuing to parrot the 97% figure uncritically like as it was some gospel. [0]
[0] http://www.joshbarczak.com/blog/?p=580
It often feels like “most people” gets trotted out when there’s no real data on the subject. In a lot of ways you’re committing the same error you’re accusing this random blogger of: believing something uncritically without actually trying to verify the claim.
Casey isn’t famous for his contributions to computer science or even game development, he’s famous for his streaming and talks. And to that, I’ll point out Jason “Thor” “PirateSoftware” Hall was also a popular devfluencer until he got on the nerves of too many people and they started investigating his claims. So the fact that Muratori is notable doesn’t hold weight.
Like I agree with most everything he says and I like to optimise my own software, but for my day to day jobs and contracts it's simply not feasible.
That level of performance and rigor is not what is demanded nor paid or appreciated.
E.g. in Enterprise circles it's still OOP from top to bottom.
Mixed with a tad more functional style due to varying adoption of that paradigm in the languages used by enterprise.
But low level optimizations are not interesting to these customers at all, even though they could help them with some problems.
I suppose it is a matter of what one works on, but that has been consistent in my career.
I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.
Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food.
I used to spend a lot of time watching crap like lex and primagen before it became obvious that these kinds of information channels are not meaningfully enriching despite sounding like they should be to a casual observer.
> Open source is the very worst thing currently going on because it is so incredibly exploitative, it's far more exploitative than any actual company is of the workers who work at the company.
> Even the people who are getting paid in open source are getting massively underpaid to do it compared to how much the people who are using their code are making, it's nothing compared to the power that is accreted by the people who have co-opted that work thanks to the open source model. And then mark zuckerberg gets to define how the internet works despite having paid for almost none of the software that his company actually needed to make that work.
> It's like feudalism or serfdom, these people did the work and got nothing for it. It's like you took the worst aspects of capitalism for workers and the worst aspects of socialism for workers and put them together, that's open source. You get no power and you get no money.
> It's exploitative whether the people chose to be exploited, just because someone chooses to let you exploit them does not mean that you didn't exploit them. And for the record that's how most exploitation works; convincing people to do something that turns out to be very bad for them and very good for you, and that's exactly what the open source movement has turned out to be.
> I really don't see the "we post stuff on github under a gpl2 or lgpl or apache or mit license", all that is to me now is just exploitation. You can say that there's solutions but until someone demonstrates that those solutions work, it's the standard "real communism has never been tried" argument. AGPL is the only thing that I've seen so far that's an attempt to fix these fundamentally unfair compensation practices.
1. Not paying for the labor corporations exploit. GPL is better here, but still imperfect. MIT/BSD is awful here. It wouldn't matter in an ideal post-scarcity society, but we don't live in that yet, so it does matter. Until post-scarcity, a better model would route revenue from exploitative capitalist uses back to the creators and/or their desired sinks.
2. The open source bait-and-switch - startups using open source to get users and then pulling up the ladder and going closed source and monopolistic once they have achieved scale to enforce/ achieve lock in.
In fact they don't seem to care about money at all, often believing all corporations/capitalism are bad, and that they and everyone else should just be poor and live in the woods or something.
When has History of any kind ever held practical value?
Casey is far more measured, careful and accurate. Casey feels like an engineering educator first, who happens to make YouTube videos. I don’t always agree with Casey’s technical opinions, but he seems like a thoughtful guy who thinks things through.
I skimmed through the video because I don't have two hours but there's no lost knowledge in it, he's going over well known papers from Dijkstra, Hoare or Knuth. The paper he bases most of the talk around Knuth's Structured Programming with go to Statements is his most often cited work, there's a very high chance you'll encounter that early in any undergrad course. So the answer to your question is, pretty much at any local uni with a CS course.
But I'm curious who you think #3 is.
I should also add that even interviews are valuable. Coders at Work is fantastic at that and drawing out technical opinions and reasoning; notably the subjects interviewed don't all agree and have sometimes drastically different work styles and preferences.
While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say, he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and then talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.
Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) A "complete" history as the top comment suggests would be better as a multi-author endeavor, if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.
It’s a pity there’s not more people like him. I’ve met some incredibly smart people in the FP world. I wish more of them made approachable YouTube videos explaining what they know. I recently learned about “Safe Haskell” which, if adapted to rust and other languages, could solve a lot of the security problems with npm and cargo. But nobody knows about it! We need FP Casey.
There's two reasons Safe Haskell is substantially worse than what Rust does. Safe Haskell works by annotating code that is safe, but that's entirely backwards. We need to annotate unsafe code, and explain in plain English exactly why it is okay in that particular instance (of course it would be better to explain in code, like, give a formal proof that is checked by the compiler, but then it isn't unsafe anymore!). Safe Haskell answer for that is to annotate good unsafe code as trustworthy, but that doesn't work because it doesn't goes in detail on why the code is trustworthy (to do so you really need to go into the details, you can't handwave it). It's the // SAFETY comments that are at the heart of Rust's unsafe, carefully explaining safety invariants that must be kept (specially important if we are modifying code), not unsafe { } blocks.
The second reason is much simpler. It's optional, and approximately nobody uses Safe Haskell or cares about it. If people used it we would have something to improve upon. So Rust achievement here is mostly sociological, it's a community of programmers that care about safety. Which is good given that a Rust program typically have much more unsafe code than a Haskell program.
Here's a thread about Safe Haskell issues https://www.reddit.com/r/haskell/comments/zwkqke/deprecating... that links to https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
And an older thread https://www.reddit.com/r/haskell/comments/msa3oq/safe_haskel...
This would guarantee - at a language level - that leftpad or log4j can’t root my computer.
Safe rust doesn’t give this guarantee. Safe code can still make arbitrary syscalls. Safe rust can convert a path string to a File. Or open arbitrary network sockets. Rust also doesn't have a way to import a crate but forbid the use of any unsafe blocks.
I want to be able to use 3rd party code from cargo without getting hacked. Right now rust does not keep me safe from these supply chain attacks.
I don’t know enough about safe Haskell to know how close it tacks to this. But that’s what I want.
But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations)
* https://hackage.haskell.org/package/bluefin
* https://hackage.haskell.org/package/effectful
https://spritely.institute/goblins/
On infection, I think it's a bit like being infected by mitochondria :)
I don't think you'll find anything like that from a General Purpose Language, so you probably want something like WUFFS [Wrangling Untrusted File Formats Safely].
https://github.com/google/wuffs
Casey points out that many of the lessons they came to were so obvious that it just became how it is done that no one even remembers it was done in any other way. In the talk the laments it makes it really hard to track down who originally came up with these ideas.
His dismissal of the argument Knuth makes regarding the hot loops could have been explored a bit better. I found it weird he didn’t mention the difference of types of programs of then vs now. Even today, in scientific code it is still absolutely the case a lot of the time that a huge chunk of the runtime comes from a single very very hot loop. It might be hidden in a library, but it’s there. Instead he focuses only on “program size”. Knuth samples where very small FORTRAN programs (compared to today’s standards). Today’s program are bigger but the fundamental number crunching primitive of “let’s compute stuff in a loop” remains. It’s just buried under a pile of extra cruft (data loading, parallelism, dispatching etc).
Now we just deal with a lot more programs that are of a whole different class compared to what they where doing with computers in the 70s. We have much more I/O involved. And hot loops don’t like being I/O bound.
iirc, in the talk casey in fact does goes on about how he tried to find examples, but couldn't. in the q&a, he was also asked about this further.
"I can't do anything because my program is I/O-bound" is more of an excuse / mental justification of why your program is slow instead of an honest reason for so.
Most of the stuff I work on is almost exclusively network I/O bound. I wouldn't say it's a _result_ of bad engineering practices, though. One group decided on a particular system that's also public-facing, and the group I actually support prefers a more internal-facing system. It also doesn't help that the budgets for both projects are completely separate and firewalled from each other by law. Growth opportunities don't apply here because I deal with a captive market with legally-forced customers.
This isn't really true anymore. IO has bad latency, but modern SSD bandwidth is ~5-15GB/s. If your program is IO latency bound and processing less that 5GB/s you aren't IO bound, you aren't hiding your latency well enough.
That's nothing compared to modern memory bandwidth.
Not anymore, no. Your SSD, before caching, does gigabytes per second of sequential reads. For any bytewise processing, except the most trivial of tasks, you’ll struggle to get above a few hundred megabytes per second with native scalar code. To actually keep up with a modern SSD, you’re virtually guaranteed to need handwritten SIMD, minimize the number of syscalls with techniques like io_uring, or possibly be smart about distributing tasks across cores without ruining the access pattern.
For instance, simdjson is famously fast but I don’t believe it can keep up with say a Samsung 990 PRO. And I know of no Unicode normalizer that would be able to do a gigabyte per second on general inputs (not ASCII, not Latin-1) simply because the RAM latency for dependent lookup table accesses is absolute murder.
And I think you’re being unfair labelling my couple of examples “some arbitrary algorithm[s]”: my choice was indeed arbitrary, but it’s also immaterial. The general setup would be that you’re processing elements in a loop and that your iterations are serialized (as they usually more or less are before you get around to optimization). A loop body of even three lines of C is likely to have a latency of 5–10 cycles or so, and you’re running on a core clocked somewhere from 5 GHz (desktop) to half that (server). So the best you should expect is ~500 MB/s if your elements are bytes, ~2 GB/s if they’re 32-bit integers, etc. For very simple tasks (that are also somehow not susceptible to vectorization), it is possible to not lose this order of magnitude and get down to almost 1 cycle/element in scalar code, but that requires heroic effort[1].
[1] https://github.com/powturbo/Turbo-Histogram
This is backwards. I bet that by count, many more programs are written in domains where they're necessarily IO bound than the inverse. Anything that uses the network for its core functionality, anything reliant on a datasource whose aggregate contents are O(memory)+ size, or anything reliant on slow peripherals (lots of embedded software) are in this class.
Scientific simulations, HFT algorithms, video games, LLMs, etc.--the stuff in the other class--aren't inconsequential, but they're dwarfed in number by the class of software that spends 99+% of its time waiting for IO. Hell, entire programming languages (node.js) have been created in response to that proportion.
And a GPU does orders of magnitude past this.
Networks are not even close.
https://chipsandcheese.com/p/a-new-year-and-new-tests-gpu-l1...
You're not wrong in that there are some programs that could be doing more work in CPU/memory while waiting for IO, but those, too, are dwarfed by the number of programs that can't really do anything meaningful until IO completes. Anything that RPCs or IPCs data is generally going to be waiting for a complete RPC IO to finish before doing compute (and even the most granular RPC protocols tend to communicate in pretty big, slow chunks to maximize throughput). Lots of software waiting on local hardware (e.g. storage) is similarly doing IOs in pretty big pieces--maybe page-sized, or disk-block-sized, or file-sized--and can't do much meaningful CPU work until that's done. In embedded, it often behooves programs to get as much IO-sourced data read or written as is possible with available resources before switching back to CPU work--doing this increases throughput on slow hardware, and can also improve power efficiency.
Latency, throughput, power, hardware cost--those often trade off, and there's no free lunch.
In saying that there are some novel and very clever algorithms that continue on without seemingly necessary boundary data, that then self correct when the data comes through, thus completely hiding the latency at the cost (in both accuracy and time) of running a correction process.
It doesn't really contain anything new or earthshattering, but if you find diving into the history of programming as a discipline interesting, it might be for you.
I would recommend it to anyone who liked the rambling style of "The big OOPs", but imo that one was better. I still liked it.
Like they can't comprehend the fact that these things only happen if there is an incentive for it
I think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a game
They are so used to working in games that they take it for granted that the business incentive for performance exists
As someone who has worked in both AAA games and big tech it just comes across as a bit naive to me
Yes it’s incentives - but why these incentives exist and not others is an interesting question to study.
In the 2010s we pushed everyone to learn how to code and maybe lost some of our higher standards. Maybe we’re doing that now with AI?
Maybe broader social and economic incentives have had a lot of short term thinking of late? It’s hard to organize society or a company to go in one direction very long before incentives completely change everything. Who knows, maybe that’s a feature, not a bug.
It’s worth asking though why we have this software industry and not another one. I’m not convinced it’s for legitimate reasons.
Then we can talk about how we all pay the increased cost in energy and materials, and so forth.
Optimizing code for max performance does take work. But just not doing incredibly dumb things and writing simple programs just takes education (and re-education).
I can’t count how many times I’ve replaced a distributed system with for loop.
It takes a lot more work to keep performance good in a large project than just letting it degrade.
I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.
He's essentially never had to deal with distributed systems, or anything that allows multiple users to use the same system, with all the performance and anti-abuse issues that come with that.
His opinions about game development are insightful, and his thoughts on craft can be quite inspiring, but I think he could benefit from a stint on a (good) big tech server team to see some of the things he's currently missing.