Joseph Garvin
@josephhgarvin.bsky.social
voicecoding latency and throughput hacker. How did I get here and what am I doing in this hand basket? he/him
Pinned
Joseph Garvin
@josephhgarvin.bsky.social
· Nov 14
Hello bsky. I post mostly about:
- Low latency programming
- Programming Language design
- Metaprogramming
- Rants
- Low latency programming
- Programming Language design
- Metaprogramming
- Rants
Most annoying sins of LLM generated code:
- Silently suppressing exceptions
- Redundant checks and size to buffers "just in case"
- Tests with magic constants from the implementation
- Adding timeouts to ops that shouldn't have them
- Short flags instead of --descriptive-flag
- Silently suppressing exceptions
- Redundant checks and size to buffers "just in case"
- Tests with magic constants from the implementation
- Adding timeouts to ops that shouldn't have them
- Short flags instead of --descriptive-flag
November 12, 2025 at 2:45 PM
Most annoying sins of LLM generated code:
- Silently suppressing exceptions
- Redundant checks and size to buffers "just in case"
- Tests with magic constants from the implementation
- Adding timeouts to ops that shouldn't have them
- Short flags instead of --descriptive-flag
- Silently suppressing exceptions
- Redundant checks and size to buffers "just in case"
- Tests with magic constants from the implementation
- Adding timeouts to ops that shouldn't have them
- Short flags instead of --descriptive-flag
"Why are there so many instantiations of this template? I only use one set of types with it."
*several minutes of reading ridiculously long types*
"Oh mothe-"
*several minutes of reading ridiculously long types*
"Oh mothe-"
November 10, 2025 at 11:06 PM
"Why are there so many instantiations of this template? I only use one set of types with it."
*several minutes of reading ridiculously long types*
"Oh mothe-"
*several minutes of reading ridiculously long types*
"Oh mothe-"
Finding goto is still relevant for code size optimization. Several early exit paths that all need to construct some return object? Better to construct and return in one place and change all the early returns to gotos. Clang/GCC don't optimize it reliably (look for -1640531527).
November 7, 2025 at 5:54 PM
Finding goto is still relevant for code size optimization. Several early exit paths that all need to construct some return object? Better to construct and return in one place and change all the early returns to gotos. Clang/GCC don't optimize it reliably (look for -1640531527).
I'm sure it will increase the quality of discourse to prevent people publicly quoting what people publicly said. Definitely won't have the unintended effect of making things easier for grifters.
November 7, 2025 at 5:09 AM
I'm sure it will increase the quality of discourse to prevent people publicly quoting what people publicly said. Definitely won't have the unintended effect of making things easier for grifters.
Compilers should let you label an inlining "cutoff point" in the middle of a func. The closest you can get is moving all the rare case code into a separate function, but then the caller still has to do arg management which bloats the func size. Clang has preserve_all at least.
November 6, 2025 at 7:05 PM
Compilers should let you label an inlining "cutoff point" in the middle of a func. The closest you can get is moving all the rare case code into a separate function, but then the caller still has to do arg management which bloats the func size. Clang has preserve_all at least.
One way to simplify C++ container implementations is to only store u32 values that index something else. u32 is almost always wide enough, it's trivially copyable and movable, there's no need to worry about emplace or variadics, no need to even template the container!
November 3, 2025 at 8:30 PM
One way to simplify C++ container implementations is to only store u32 values that index something else. u32 is almost always wide enough, it's trivially copyable and movable, there's no need to worry about emplace or variadics, no need to even template the container!
Chat, should I write a linker?
November 2, 2025 at 9:40 PM
Chat, should I write a linker?
Trying out lld in place of GNU ld and finding the compatibility very iffy, -e and script support showing discrepancies. Wondering how many embedded devs are really using this or if it's all desktop/server where these features see less use.
November 2, 2025 at 9:15 PM
Trying out lld in place of GNU ld and finding the compatibility very iffy, -e and script support showing discrepancies. Wondering how many embedded devs are really using this or if it's all desktop/server where these features see less use.
Watching the @chandlerc.blog talk comparing the C++ -> Rust porting experience to the future hypothetical C++ -> Carbon experience. Great minimal example (timestamped link 👇) matching my experience where writing unsafe Rust can be more error prone than writing unsafe C++!
October 28, 2025 at 5:08 PM
Watching the @chandlerc.blog talk comparing the C++ -> Rust porting experience to the future hypothetical C++ -> Carbon experience. Great minimal example (timestamped link 👇) matching my experience where writing unsafe Rust can be more error prone than writing unsafe C++!
Does anyone have any rules of thumb for predicting when untemplating code is more likely to cause I$ misses than templating it? Templated code can make direct calls that are easier to predict but generates more code, untemplated code is smaller but will use function pointers.
October 26, 2025 at 10:07 PM
Does anyone have any rules of thumb for predicting when untemplating code is more likely to cause I$ misses than templating it? Templated code can make direct calls that are easier to predict but generates more code, untemplated code is smaller but will use function pointers.
Pop quiz: Can you guess what this prints and why?
October 24, 2025 at 6:56 PM
Pop quiz: Can you guess what this prints and why?
Can you spot the bug?
October 20, 2025 at 5:29 PM
Can you spot the bug?
The decision to make every lambda be a unique anonymous type has been a disaster for C++ error readability. It does make sense from a type system standpoint though.
October 19, 2025 at 9:56 PM
The decision to make every lambda be a unique anonymous type has been a disaster for C++ error readability. It does make sense from a type system standpoint though.
Lay people won't appreciate why this is impressive but this is one of the craziest things I've seen GPT5 do. I gave it this graph from FT and asked it to add Facebook adoption for comparison, and rather than generate a new graph it seemingly correctly superimposed a new line!
October 19, 2025 at 5:40 PM
Lay people won't appreciate why this is impressive but this is one of the craziest things I've seen GPT5 do. I gave it this graph from FT and asked it to add Facebook adoption for comparison, and rather than generate a new graph it seemingly correctly superimposed a new line!
In hash table APIs where lookups return pointers rather than iterators, you face the issue that a lookup followed by an erase (b/c you need to do some work on the item before erasing) is 2x lookup work. So then erase needs an on_found callback, or instead of erase you need take.
October 17, 2025 at 8:04 PM
In hash table APIs where lookups return pointers rather than iterators, you face the issue that a lookup followed by an erase (b/c you need to do some work on the item before erasing) is 2x lookup work. So then erase needs an on_found callback, or instead of erase you need take.
So is it just the same old farts talking to each other now?
October 16, 2025 at 8:37 PM
So is it just the same old farts talking to each other now?
People diss the C++ STL because of perf but there are interesting ideas in it. Making the leap from using pointers to crawl structures to using iterator objects with pointer syntax to being generic over both was an interesting trick that Rust chose not to copy.
October 16, 2025 at 7:40 PM
People diss the C++ STL because of perf but there are interesting ideas in it. Making the leap from using pointers to crawl structures to using iterator objects with pointer syntax to being generic over both was an interesting trick that Rust chose not to copy.
Every behavior my software relies on in yours is sacred, every behavior your software relies on in mine is technical debt.
October 16, 2025 at 1:40 AM
Every behavior my software relies on in yours is sacred, every behavior your software relies on in mine is technical debt.
Working in C++ one of the few big things I miss for metaprogramming compared to Rust is rustdoc. Headers don't work well as your lib docs when your interfaces are generated by a ton of magic, but big interfaces generated by Rust macros can still result in readable docs.
October 12, 2025 at 9:32 PM
Working in C++ one of the few big things I miss for metaprogramming compared to Rust is rustdoc. Headers don't work well as your lib docs when your interfaces are generated by a ton of magic, but big interfaces generated by Rust macros can still result in readable docs.
HashTable needs try_insert, replace, upsert. And lazy versions that take a closure and construct if no existing key. And you want to be able to pass through a ctx param if your extract_key(Ctx,V)->K function needs it b/c V is an index into another container. So 12 overloads? 💀
October 9, 2025 at 10:10 PM
HashTable needs try_insert, replace, upsert. And lazy versions that take a closure and construct if no existing key. And you want to be able to pass through a ctx param if your extract_key(Ctx,V)->K function needs it b/c V is an index into another container. So 12 overloads? 💀
No but really, compilers are not that smart (at least GCC isn't, Clang gets it).
October 8, 2025 at 8:34 PM
No but really, compilers are not that smart (at least GCC isn't, Clang gets it).
"Box" seems like bad terminology when the whole point of using Vec<Box<T>> instead of Vec<T> is that moving the box does not move what is inside of it. I don't know of any real life box that works that way! If anything I'd naively expect Box to mean T is stored directly.
October 8, 2025 at 1:55 AM
"Box" seems like bad terminology when the whole point of using Vec<Box<T>> instead of Vec<T> is that moving the box does not move what is inside of it. I don't know of any real life box that works that way! If anything I'd naively expect Box to mean T is stored directly.
Don't flatter me Claude
October 7, 2025 at 9:08 PM
Don't flatter me Claude
Compilers are not *that* smart
October 5, 2025 at 4:01 PM
Compilers are not *that* smart
Instead of HashTable<K, V> you can have HashTable<V> where you give extract(V) -> K, since often V contains K anyway, so HashTable<K, V> stores every K 2x. HashTable<Pair<K,V>> gives old behavior. But, HashTable<V> breaks emplace, since you need to create V to extract K! Annoying
September 30, 2025 at 3:26 PM
Instead of HashTable<K, V> you can have HashTable<V> where you give extract(V) -> K, since often V contains K anyway, so HashTable<K, V> stores every K 2x. HashTable<Pair<K,V>> gives old behavior. But, HashTable<V> breaks emplace, since you need to create V to extract K! Annoying