1263870017365348353, 1261404927106015232, 1261391216110743552, 1247299604690829313, 1235037224976044034, 1443886672001765393, 1315709348291772417, 1602460104452100096, 1261404927106015232, 1594772462289715201

2026-08-27 22:54:34 -04:00
1 parent 8c5b512e8a
commit 490238ce89
@@ -67,7 +67,9 @@ jobs:
        run: python ../publish/quartz-patches/apply.py search
      - name: Build Quartz
        working-directory: site
-        run: npx quartz build -d ..
+        run: NODE_OPTIONS=--max-old-space-size=4096 npx quartz build -d .. --concurrency 8
        env:
          NODE_OPTIONS: --max-old-space-size=4096
      - name: Rewrite built HTML
        working-directory: site
        run: python ../publish/quartz-patches/apply.py built
@@ -0,0 +1,112 @@
 ---
 title: "@AllenWebster4th IMO the real reason to avoid `malloc` nowadays (for any device with virtual addressing) is to avoid the internal lock contention."
 type: archive
 source: twitter
 source_url: "https://x.com/RandyPGaul/status/1594772462289715201"
 author: "Randy Gaul"
 handle: RandyPGaul
 post_id: "1594772462289715201"
 date: 2022-11-21
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - RandyPGaul
 description: "@AllenWebster4th IMO the real reason to avoid `malloc` nowadays (for any device with virtual addressing) is to avoid the internal lock contention."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/RandyPGaul/status/1594772462289715201
 - Author: Randy Gaul (@RandyPGaul)
 - Posted: 2022-11-21 19:19:19
 ## Thread
 **1/** **@RandyPGaul** ^1594772462289715201
 **@AllenWebster4th**
 IMO the real reason to avoid `malloc` nowadays (for any device with virtual addressing) is to avoid the internal lock contention. Arena doesn't really help much here beyond preventing fragmentation within pages, which imo is still not that great of a benefit.
 **2/** **@rfleury** ^1594778888861020160
 **@RandyPGaul** **@AllenWebster4th**
 Unfortunately there is a huge lack of precision in the terms. Arenas—or at least what I mean by arenas—are growing linear/stack allocators with explicit handles. They don’t have any locking mechanism. This can dramatically *help* with synchronization.
 **3/** **@rfleury** ^1594780740532985856
 **@RandyPGaul** **@AllenWebster4th**
 (Specifically because the natural usage pattern is to not allow, generally, one arena to cross the boundary between two threads, unless you’re explicitly making an interlocked synchronized data structure or something of the sort)
 **4/** **@RandyPGaul** ^1594782194647855104
 **@rfleury** **@AllenWebster4th**
 Yeah if it’s thread local then you got it. But that’s a pretty strong limitation for “general use”.
 Main thing of interest to me is framing contention as the primary concern as opposed to fragmentation
 **5/** **@RandyPGaul** ^1594783978875392000
 **@rfleury** **@AllenWebster4th**
 Example cute_tiled.h https://github.com/RandyGaul/cute_headers/blob/master/cute_tiled.h a SFH lib for parsing JSON maps created by https://www.mapeditor.org/ uses an arena allocator. I actually really regret it. Complicates code unnecessarily and provides almost no practical benefit to anyone using the lib.
 **6/** **@rfleury** ^1594788957728174080
 **@RandyPGaul** **@AllenWebster4th**
 This is why I think there is some misunderstanding regarding the terminology. Thread-local allocation isn’t prohibitive for general use, it’s what you want by default, with minimal (and explicit) cross-thread communication.
 **7/** **@rfleury** ^1594789248385056770
 **@RandyPGaul** **@AllenWebster4th**
 Furthermore, I haven’t looked at your library much, but in the Metadesk library—a very similar problem—we also use arenas, and our experience was entirely different. On the surface, it looks like we have very different ideas about what arenas are and what they mean to the caller.
 **8/** **@RandyPGaul** ^1594798522024734720
 **@rfleury** **@AllenWebster4th**
 What’s different in your experience? Just curious for discussion’s sake, not trying to prod or anything 😊
 **9/** **@rfleury** ^1594815318819737601
 **@RandyPGaul** **@AllenWebster4th**
 Twitter is low bandwidth so it’s impossible to be anything but low detail, but basically everything — arenas have helped simplify APIs, simplify allocation, improve performance, and eliminate bugs. I can’t be much more precise but a lot of the reasoning is embedded in the API.
 **10/** **@RandyPGaul** ^1594830594307166209
 **@rfleury** **@AllenWebster4th**
 I see you used it in your API. API aside, in terms of threading MD is single-threaded internally, yes? I'd be curious to see a use-case example from customer PoV where the arenas lowered threading contention
 **11/** **@RandyPGaul** ^1594832245264896000
 **@rfleury** **@AllenWebster4th**
 Usually for parser/loader kind of tasks I see them happen once at startup and never again, so lock contention on malloc usually a non-existent priority. Maybe MD is used differently than this?
 **12/** **@rfleury** ^1594854847500922881
 **@RandyPGaul** **@AllenWebster4th**
 Metadesk’s implementation is single threaded in the sense that it contains no synchronization, but this is because it’s strictly organized as stateless, data-in-data-out transforms. Multithreading occurs by bucketing these transforms (and their arenas) on different threads.
 **13/** **@rfleury** ^1594855461047914496
 **@RandyPGaul** **@AllenWebster4th**
 Arenas do not solve contention, but they don’t promote usage patterns that introduce unnecessary contention. They’re useful building blocks in bucketing allocations and work, which is exactly what you need for minimizing contention.
 **14/** **@RandyPGaul** ^1594872404408696832
 **@rfleury** **@AllenWebster4th**
 Makes sense thanks for explaining!
@@ -0,0 +1,12 @@
 ---
 title: RandyPGaul
 type: note
 draft: false
 description: Archived threads by RandyPGaul.
 tags:
  - archive
  - twitter
  - RandyPGaul
 ---
 - [[archive/threads/RandyPGaul/2022-11-21-imo-the-real-reason-to-avoid-malloc-nowadays-for]]
@@ -0,0 +1,62 @@
 ---
 title: "@DionSystems @rfleury What editor is this..."
 type: archive
 source: twitter
 source_url: "https://x.com/danishnxt/status/1315709348291772417"
 author: "Danish | دانش"
 handle: danishnxt
 post_id: "1315709348291772417"
 date: 2020-10-12
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - danishnxt
 description: "@DionSystems @rfleury What editor is this..."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/danishnxt/status/1315709348291772417
 - Author: Danish | دانش (@danishnxt)
 - Posted: 2020-10-12 17:42:07
 ## Thread
 **1/** **@danishnxt** ^1315709348291772417
 **@DionSystems** **@rfleury**
 What editor is this...
 **2/** **@ongamex92** ^1315709990066413573
 **@danishnxt** **@DionSystems** **@rfleury**
 Not sure, but it looks like 4coder
 **3/** **@rfleury** ^1315710601604329473
 **@ongamex92** **@danishnxt** **@DionSystems**
 This is Dion, a new programming engine we (@DionSystems) are working on. We will be presenting it at this year's Handmade Seattle conference (@handmade_seattl).
 **4/** **@helioscomm** ^1316222884243820550
 **@rfleury** **@ongamex92** **@danishnxt** **@DionSystems** **@handmade_seattl**
 Wow, it's really beautiful. Is it showing us some Haskell, or does Dion go hand-in-hand-with a new language also called Dion?
 **5/** **@rfleury** ^1316227665221890049
 **@helioscomm** **@ongamex92** **@danishnxt** **@DionSystems** **@handmade_seattl**
 It is a custom language also for a number of technical and research benefits. We're currently also calling the language Dion but we will see how confusing that gets. :)
 **6/** **@helioscomm** ^1316367675048693761
 **@rfleury** **@ongamex92** **@danishnxt** **@DionSystems** **@handmade_seattl**
 Very exciting; looking forward to see how it compares to Haskell, Idris et Al. And what you can do with it IRL. And whether it'll have Wasm as a compile target! 😻
@@ -0,0 +1,12 @@
 ---
 title: danishnxt
 type: note
 draft: false
 description: Archived threads by danishnxt.
 tags:
  - archive
  - twitter
  - danishnxt
 ---
 - [[archive/threads/danishnxt/2020-10-12-what-editor-is-this]]
@@ -21,6 +21,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/CharlieMQV]]
 - [[archive/threads/ChipsandCheese9]]
 - [[archive/threads/cmuratori]]
 - [[archive/threads/danishnxt]]
 - [[archive/threads/Dispatch_Graph]]
 - [[archive/threads/EricLengyel]]
 - [[archive/threads/FFmpeg]]
@@ -41,6 +42,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/mike_acton]]
 - [[archive/threads/MissQuickstep]]
 - [[archive/threads/mmalex]]
 - [[archive/threads/molecularmusing]]
 - [[archive/threads/MyNameIsMJP]]
 - [[archive/threads/nicbarkeragain]]
 - [[archive/threads/no1zex]]
@@ -48,6 +50,7 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
 - [[archive/threads/NOTimothyLottes]]
 - [[archive/threads/ocornut]]
 - [[archive/threads/pikuma]]
 - [[archive/threads/RandyPGaul]]
 - [[archive/threads/rfleury]]
 - [[archive/threads/rianflo]]
 - [[archive/threads/rygorous]]
@@ -0,0 +1,58 @@
 ---
 title: "I have an honest question: how do *you* deal with all the broken software if it seriously impedes your daily work?"
 type: archive
 source: twitter
 source_url: "https://x.com/molecularmusing/status/1443886672001765393"
 author: "Stefan Reinalter"
 handle: molecularmusing
 post_id: "1443886672001765393"
 date: 2021-10-01
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - molecularmusing
 description: "I have an honest question: how do *you* deal with all the broken software if it seriously impedes your daily work?"
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/molecularmusing/status/1443886672001765393
 - Author: Stefan Reinalter (@molecularmusing)
 - Posted: 2021-10-01 10:33:03
 ## Thread
 **1/** **@molecularmusing** ^1443886672001765393
 I have an honest question: how do *you* deal with all the broken software if it seriously impedes your daily work?
 I mean, this week alone I filed 7 bugs in total, with 3 major companies.
 How do you cope? What's your strategy if this hinders you in getting work done?
 **2/** **@rfleury** ^1443929965850857474
 **@molecularmusing**
 I prefer to minimize dependencies, keep everything local (libraries, tools) when possible, and upgrading when *I* choose to do so. Libraries, ideally, are simply-built source files included directly into the codebase.
 **3/** **@molecularmusing** ^1443932063086923776
 **@rfleury**
 The three biggest dependencies for me are Windows, VS, and Qt.
 All are monolithic behemoths where fixing stuff myself is either impossible (Win10, VS), or tiresome to report bugs (all 3 of them).
 I would love to actually be able to fix stuff myself, eventhough I shouldn't have to
 **4/** **@molecularmusing** ^1443932330381414401
 **@rfleury**
 Maybe I should look more at OSS stuff, use the Clang toolchain and other editors for my dev work, but then I'm still stuck with having to support VS for my software.
 **5/** **@rfleury** ^1443951646250205187
 **@molecularmusing**
 Yeah VS is unfortunate, sounds like you’re not exactly in the best situation :( I think of all dependent technologies as a foundation, and so I want it to be as static and predictable as possible. Sometimes that’s not possible, though, unfortunately…
@@ -0,0 +1,12 @@
 ---
 title: molecularmusing
 type: note
 draft: false
 description: Archived threads by molecularmusing.
 tags:
  - archive
  - twitter
  - molecularmusing
 ---
 - [[archive/threads/molecularmusing/2021-10-01-i-have-an-honest-question-how-do-you-deal-with]]
@@ -0,0 +1,73 @@
 ---
 title: "New programming blog post about the complexity and performance trade-offs of maintaining entity memory contiguity in games."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1235037224976044034"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1235037224976044034"
 date: 2020-03-04
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "New programming blog post about the complexity and performance trade-offs of maintaining entity memory contiguity in games."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1235037224976044034
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-03-04 02:59:54
 ## Thread
 **1/** **@rfleury** ^1235037224976044034
 New programming blog post about the complexity and performance trade-offs of maintaining entity memory contiguity in games.
 #programming #gamedev 
 https://ryanfleury.net/blog_entity_memory_contiguity
 **2/** **@simplex_fx** ^1235160069026844673
 **@rfleury**
 "This is also why, in my estimation, it is not a good idea for a game engine that supports many possible games to enforce this kind of design structure on gameplay code, because it constrains design ideas"
 Could you elaborate on this? :)
 **3/** **@rfleury** ^1235223001504698368
 **@simplex_fx**
 Yes—engines often are opinionated about entities, and enforce some of generic model in which entities are defined. This doesn't seem like a net win to me, since different games have different problems, and different entity structures lend themselves better to different problems.
 **4/** **@simplex_fx** ^1235255274572742656
 **@rfleury**
 ECS has nothing to do with how entities are defined.
 There could be generic micro components, and systems, but there could be big, and/or specialized ones too.
 You could still have an entity archetype with just one big component.
 **5/** **@rfleury** ^1235261483740565504
 **@simplex_fx**
 I didn't argue against any of that. I just said that ECS is designed to solve a specific problem, and therefore it's a specific solution. The blog post isn't about any of this.
 **6/** **@simplex_fx** ^1235268864222670848
 **@rfleury**
 ECS is not designed to solve a specific problem. It just means, that you keep data, relations between data, and transformations on the data separated.
 I don't see, how it constrains design ideas. 
 But it could certainly allow drastic improvements in entity memory contiguity.
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury I'm that kind of person who asks the \"why\" of things, and how they were made from its core, but by not \"re-inventing the wheel\" you can save a lot of time."
 type: archive
 source: twitter
 source_url: "https://x.com/felixzsh/status/1247335046643507200"
 author: "Felix Sanchez"
 handle: felixzsh
 post_id: "1247335046643507200"
 date: 2020-04-07
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury I'm that kind of person who asks the \"why\" of things, and how they were made from its core, but by not \"re-inventing the wheel\" you can save a lot of time."
 in_reply_to: ""
 parent_post_id: "1247299612886487041"
 ---
 ## Source
 - URL: https://x.com/felixzsh/status/1247335046643507200
 - Author: Felix Sanchez (@felixzsh)
 - Posted: 2020-04-07 01:27:04
 ## Branch
 **1/** **@felixzsh** ^1247335046643507200
 **@rfleury**
 I'm that kind of person who asks the "why" of things, and how they were made from its core, but by not "re-inventing the wheel" you can save a lot of time.
 ## Related
 - Spine: [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury Nowadays there are a lot of software done and debugged to be used, the way i see that fact is, that thanks to that software you can create new software faster...."
 type: archive
 source: twitter
 source_url: "https://x.com/felixzsh/status/1247335707980353536"
 author: "Felix Sanchez"
 handle: felixzsh
 post_id: "1247335707980353536"
 date: 2020-04-07
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury Nowadays there are a lot of software done and debugged to be used, the way i see that fact is, that thanks to that software you can create new software faster...."
 in_reply_to: ""
 parent_post_id: "1247299612886487041"
 ---
 ## Source
 - URL: https://x.com/felixzsh/status/1247335707980353536
 - Author: Felix Sanchez (@felixzsh)
 - Posted: 2020-04-07 01:29:41
 ## Branch
 **1/** **@felixzsh** ^1247335707980353536
 **@rfleury**
 Nowadays there are a lot of software done and debugged to be used, the way i see that fact is, that thanks to that software you can create new software faster.... And so on.
 ## Related
 - Spine: [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury Just a conversation on this topic today."
 type: archive
 source: twitter
 source_url: "https://x.com/SasLuca/status/1247682432901447680"
 author: "Luca"
 handle: SasLuca
 post_id: "1247682432901447680"
 date: 2020-04-08
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury Just a conversation on this topic today."
 in_reply_to: ""
 parent_post_id: "1247299612886487041"
 ---
 ## Source
 - URL: https://x.com/SasLuca/status/1247682432901447680
 - Author: Luca (@SasLuca)
 - Posted: 2020-04-08 00:27:27
 ## Branch
 **1/** **@SasLuca** ^1247682432901447680
 **@rfleury**
 Just a conversation on this topic today. Centralizing allocations and using allocators is incredibly powerful and not just for performance but also reliability and simplicity.
 ## Related
 - Spine: [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to]]
@@ -0,0 +1,52 @@
 ---
 title: "It is unfortunate that programmers are taught to ignore memory in favor of using RAII/GC/ARC/etc., despite that using memory constraints to one's advantage can dramatically improve speed, improve reliability, improve debuggability and reduce code complexity."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1247299604690829313"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1247299604690829313"
 date: 2020-04-06
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "It is unfortunate that programmers are taught to ignore memory in favor of using RAII/GC/ARC/etc., despite that using memory constraints to one's advantage can dramatically improve speed, improve reliability, improve debuggability and reduce code complexity."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1247299604690829313
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-04-06 23:06:14
 ## Thread
 **1/** **@rfleury** ^1247299604690829313
 It is unfortunate that programmers are taught to ignore memory in favor of using RAII/GC/ARC/etc., despite that using memory constraints to one's advantage can dramatically improve speed, improve reliability, improve debuggability and reduce code complexity.
 **2/** **@rfleury** ^1247299606440038402
 It seems that the idea that memory requirements should be abstracted away from the programmer, instead of being a tool to solve a problem, is one of the biggest mistakes of the status quo in software engineering.
 **3/** **@rfleury** ^1247299608268509185
 I was once told to use the CRT's allocator instead of my own linear allocator for a problem because there would be no way that I write a hand-rolled routine that would beat malloc. The fallacy is that the authors of CRT's malloc for my compiler and I were solving two problems.
 **4/** **@rfleury** ^1247299609954668544
 Allocating off of a linear allocator is simple. You return a pointer and increment the allocation position. At the end, you just reset that position to 0. This not only simplifies allocation code (batch freeing), it also is dramatically faster than a generic malloc...
 **5/** **@rfleury** ^1247299611435257856
 ...and yet in both education and (*some* places in) the industry, programmers are discouraged from taking advantage of situations like this, to ensure nobody is "re-inventing the wheel".
 **6/** **@rfleury** ^1247299612886487041
 What do you get for not "re-inventing the wheel"? Worse reliability, worse speed, more complicated code. Where is the tradeoff?
 Branches: [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to/2020-04-07-felixzsh-im-that-kind-of-person-who-asks-the-why-of-things]], [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to/2020-04-07-felixzsh-nowadays-there-are-a-lot-of-software-done-and]], [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to/2020-04-08-SasLuca-just-a-conversation-on-this-topic-today]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury @thnewlands @kevinwatters this is really special ty"
 type: archive
 source: twitter
 source_url: "https://x.com/Cabbibo/status/1261391856606212096"
 author: "Cabbibo"
 handle: Cabbibo
 post_id: "1261391856606212096"
 date: 2020-05-15
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury @thnewlands @kevinwatters this is really special ty"
 in_reply_to: ""
 parent_post_id: "1261391216110743552"
 ---
 ## Source
 - URL: https://x.com/Cabbibo/status/1261391856606212096
 - Author: Cabbibo (@Cabbibo)
 - Posted: 2020-05-15 20:23:48
 ## Branch
 **1/** **@Cabbibo** ^1261391856606212096
 **@rfleury** **@thnewlands** **@kevinwatters**
 this is really special ty
 ## Related
 - Spine: [[archive/threads/rfleury/2020-05-15-it-is-roughly-2-months-in]]
@@ -0,0 +1,34 @@
 ---
 title: "@thnewlands @kevinwatters It is roughly 2 months in."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1261391216110743552"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1261391216110743552"
 date: 2020-05-15
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@thnewlands @kevinwatters It is roughly 2 months in."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1261391216110743552
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-05-15 20:21:16
 ## Thread
 **1/** **@rfleury** ^1261391216110743552
 **@thnewlands** **@kevinwatters**
 It is roughly 2 months in.
 Branches: [[archive/threads/rfleury/2020-05-15-it-is-roughly-2-months-in/2020-05-15-Cabbibo-this-is-really-special-ty]]
@@ -0,0 +1,46 @@
 ---
 title: "@cullend @GolerGkA @star_door_ @kevinwatters To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1261404927106015232"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1261404927106015232"
 date: 2020-05-15
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@cullend @GolerGkA @star_door_ @kevinwatters To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing."
 in_reply_to: "1261386989909114880"
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1261404927106015232
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-05-15 21:15:45
 ## Thread
 **1/** **@rfleury** ^1261404927106015232
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing.
 **2/** **@rfleury** ^1261406775577677824
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 Here are a couple of other interesting GIFs to showcase a little bit more:
 <video controls src="https://video.twimg.com/tweet_video/EYFqqniUcAIYTRY.mp4"></video>
 **3/** **@rfleury** ^1261406850869686273
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 <video controls src="https://video.twimg.com/tweet_video/EYFq01hU0AAUfs9.mp4"></video>
@@ -0,0 +1,51 @@
 ---
 title: "@cullend @GolerGkA @star_door_ @kevinwatters To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1261404927106015232"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1261404927106015232"
 date: 2020-05-15
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@cullend @GolerGkA @star_door_ @kevinwatters To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing."
 in_reply_to: ""
 parent_post_id: "1261386989909114880"
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1261404927106015232
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-05-15 21:15:45
 ## Branch
 **1/** **@rfleury** ^1261404927106015232
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 To clarify, the mouse controls are just a small editor feature, not really a demonstration of the most important parts of the code editing.
 **2/** **@rfleury** ^1261406775577677824
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 Here are a couple of other interesting GIFs to showcase a little bit more:
 <video controls src="https://video.twimg.com/tweet_video/EYFqqniUcAIYTRY.mp4"></video>
 **3/** **@rfleury** ^1261406850869686273
 **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 <video controls src="https://video.twimg.com/tweet_video/EYFq01hU0AAUfs9.mp4"></video>
 ## Related
 - Spine: [[archive/threads/rfleury/2020-05-22-haha-very-true-in-my-mind-the-preferable-ui-ux]]
@@ -0,0 +1,56 @@
 ---
 title: "@yunruse @cullend @GolerGkA @star_door_ @kevinwatters Haha, very true! In my mind, the preferable UI/UX model for an AST editor is an open question right now, but what I will say is that even the simplest possible controls I thought of turned out to be preferable over text."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1263870017365348353"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1263870017365348353"
 date: 2020-05-22
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@yunruse @cullend @GolerGkA @star_door_ @kevinwatters Haha, very true! In my mind, the preferable UI/UX model for an AST editor is an open question right now, but what I will say is that even the simplest possible controls I thought of turned out to be preferable over text."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1263870017365348353
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2020-05-22 16:31:08
 ## Thread
 **1/** **@rfleury** ^1263870017365348353
 **@yunruse** **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 Haha, very true! In my mind, the preferable UI/UX model for an AST editor is an open question right now, but what I will say is that even the simplest possible controls I thought of turned out to be preferable over text. Operations that are singular in semantic meaning... (1/5)
 **2/** **@rfleury** ^1263870056938696704
 **@yunruse** **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 ...actually end up being mapped to a singular control, bringing intention of the user much closer to consequences. An example is making a struct. In a text editor, that's several keypresses ('struct', 'name', '{', '\n', so on). In the simplest scheme here, it's one. (2/5)
 **3/** **@rfleury** ^1263870082536452097
 **@yunruse** **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 Just from using the editor myself as it is right now, this has been a much more comfortable editing experience, because there is less busywork when it comes to specifying some semantic concept. (3/5)
 **4/** **@rfleury** ^1263870114895499264
 **@yunruse** **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 At some point I realized that it isn't much different from any other kind of program. If we build an image editor, we don't ask the artist to type "save", we give them a button to do so, and once they are comfortable, we also have a keybinding. (4/5)
 **5/** **@rfleury** ^1263870137414742016
 **@yunruse** **@cullend** **@GolerGkA** **@star_door_** **@kevinwatters**
 Furthermore, code is just another form of data, so we can develop editors for it in the same way. I think this can improve input paradigms a lot, and can get us to a place where our programming tools are much smarter and more capable. (5/5)
@@ -0,0 +1,62 @@
 ---
 title: "@nex3 https://handmade.network/manifesto"
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1392854205807796226"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1392854205807796226"
 date: 2021-05-13
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@nex3 https://handmade.network/manifesto"
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1392854205807796226
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2021-05-13 14:48:15
 ## Thread
 **1/** **@rfleury** ^1392854205807796226
 **@nex3**
 https://handmade.network/manifesto
 **2/** **@SuddenlyWizards** ^1392871114582355977
 **@rfleury** **@nex3**
 Serious question, this document appears to put performance at odds with code readability, is the idea here saying that performances the only thing that matters? And if it means better speed the code can be arcane mess? I'm just a little confused by the tone.
 **3/** **@rfleury** ^1392876041132285954
 **@SuddenlyWizards** **@nex3**
 No, I don't think so.
 For me, the point of the manifesto is purely that we are writing real code for real machines, in real circumstances,  with real teams, for real users.
 Code readability is useful insofar as it helps us do that.
 It is not the point of software, however.
 **4/** **@rfleury** ^1392876496134590467
 **@SuddenlyWizards** **@nex3**
 To that point, with regards to the original post, the tradeoffs of "code reusability" are often not measured, nor are they even considered. It is simply assumed that writing things from scratch is fundamentally worse, will take longer, and will be less robust.
 **5/** **@rfleury** ^1392876700367785989
 **@SuddenlyWizards** **@nex3**
 This is just not true in my experience, and the industry's attitude towards "code reusability", at large, seems to be more religiosity than much else.
@@ -0,0 +1,46 @@
 ---
 title: "@nice_byte This GitHub issue is detestable and hard to read."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1415097112182853634"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1415097112182853634"
 date: 2021-07-13
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@nice_byte This GitHub issue is detestable and hard to read."
 in_reply_to: "1414802543012585499"
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1415097112182853634
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2021-07-13 23:53:37
 ## Thread
 **1/** **@rfleury** ^1415097112182853634
 **@nice_byte**
 This GitHub issue is detestable and hard to read. But I don't agree that Casey is responsible for what other people do or say.
 To clarify publicly, this person was banned from @handmade_net (a while ago), and I'd like people to know that this is not how our community operates.
 **2/** **@BrookeHodgman** ^1415097636730724355
 **@rfleury** **@nice_byte** **@handmade_net**
 That kind of thing is his entire schtick though...
 **3/** **@rfleury** ^1415098731943321602
 **@BrookeHodgman** **@nice_byte** **@handmade_net**
 He's still not responsible for what other people do; he's responsible for what *he* does. This is a different person—without credentials—and the nature of the GitHub issue's contents are very different.
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury @mintyModulo It's because most debuggers suck, not to mention most are text based and not GUI based"
 type: archive
 source: twitter
 source_url: "https://x.com/hasen_95dx/status/1602471630592040960"
 author: "ハセン حسن"
 handle: hasen_95dx
 post_id: "1602471630592040960"
 date: 2022-12-13
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury @mintyModulo It's because most debuggers suck, not to mention most are text based and not GUI based"
 in_reply_to: ""
 parent_post_id: "1602460104452100096"
 ---
 ## Source
 - URL: https://x.com/hasen_95dx/status/1602471630592040960
 - Author: ハセン حسن (@hasen_95dx)
 - Posted: 2022-12-13 01:13:03
 ## Branch
 **1/** **@hasen_95dx** ^1602471630592040960
 **@rfleury** **@mintyModulo**
 It's because most debuggers suck, not to mention most are text based and not GUI based
 ## Related
 - Spine: [[archive/threads/rfleury/2022-12-13-its-an-incredibly-useful-skill]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury @mintyModulo thanks, unix"
 type: archive
 source: twitter
 source_url: "https://x.com/tumult/status/1602461137945391104"
 author: "cancel/tumult"
 handle: tumult
 post_id: "1602461137945391104"
 date: 2022-12-13
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury @mintyModulo thanks, unix"
 in_reply_to: ""
 parent_post_id: "1602460104452100096"
 ---
 ## Source
 - URL: https://x.com/tumult/status/1602461137945391104
 - Author: cancel/tumult (@tumult)
 - Posted: 2022-12-13 00:31:22
 ## Branch
 **1/** **@tumult** ^1602461137945391104
 **@rfleury** **@mintyModulo**
 thanks, unix
 ## Related
 - Spine: [[archive/threads/rfleury/2022-12-13-its-an-incredibly-useful-skill]]
@@ -0,0 +1,34 @@
 ---
 title: "@mintyModulo It’s an incredibly useful skill."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1602460104452100096"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1602460104452100096"
 date: 2022-12-13
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@mintyModulo It’s an incredibly useful skill."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1602460104452100096
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2022-12-13 00:27:15
 ## Thread
 **1/** **@rfleury** ^1602460104452100096
 **@mintyModulo**
 It’s an incredibly useful skill. The original tweet says “you need to look closer”… what is a better way to “look closer” than step through the code, line by line, and observe what’s happening? The anti-debugger sentiment floating around the industry is so bizarre.
 Branches: [[archive/threads/rfleury/2022-12-13-its-an-incredibly-useful-skill/2022-12-13-tumult-thanks-unix]], [[archive/threads/rfleury/2022-12-13-its-an-incredibly-useful-skill/2022-12-13-hasen_95dx-its-because-most-debuggers-suck-not-to-mention]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury @AbnerCoimbre @sssmcgrath Thanks for sharing this."
 type: archive
 source: twitter
 source_url: "https://x.com/Mythiqke/status/1608311748993470466"
 author: "Mythique"
 handle: Mythiqke
 post_id: "1608311748993470466"
 date: 2022-12-29
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury @AbnerCoimbre @sssmcgrath Thanks for sharing this."
 in_reply_to: ""
 parent_post_id: "1608286249499910145"
 ---
 ## Source
 - URL: https://x.com/Mythiqke/status/1608311748993470466
 - Author: Mythique (@Mythiqke)
 - Posted: 2022-12-29 03:59:36
 ## Branch
 **1/** **@Mythiqke** ^1608311748993470466
 **@rfleury** **@AbnerCoimbre** **@sssmcgrath**
 Thanks for sharing this. That's a nice article!
 ## Related
 - Spine: [[archive/threads/rfleury/2022-12-29-ah-good-important-clarification-frankly-i-wouldnt]]
@@ -0,0 +1,37 @@
 ---
 title: "@rfleury @AbnerCoimbre @sssmcgrath Go open-source"
 type: archive
 source: twitter
 source_url: "https://x.com/PLyczkowski/status/1608291978311073792"
 author: "Paweł Łyczkowski"
 handle: PLyczkowski
 post_id: "1608291978311073792"
 date: 2022-12-29
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@rfleury @AbnerCoimbre @sssmcgrath Go open-source"
 in_reply_to: ""
 parent_post_id: "1608286249499910145"
 ---
 ## Source
 - URL: https://x.com/PLyczkowski/status/1608291978311073792
 - Author: Paweł Łyczkowski (@PLyczkowski)
 - Posted: 2022-12-29 02:41:02
 ## Branch
 **1/** **@PLyczkowski** ^1608291978311073792
 **@rfleury** **@AbnerCoimbre** **@sssmcgrath**
 Go open-source
 ## Related
 - Spine: [[archive/threads/rfleury/2022-12-29-ah-good-important-clarification-frankly-i-wouldnt]]
@@ -0,0 +1,42 @@
 ---
 title: "@AbnerCoimbre @sssmcgrath Ah good, important clarification :) Frankly I wouldn’t care for the project if it wasn’t held up as an important project in the Handmade sphere via avenues like HMS, so I think it’s relevant to distance myself from what I’d call bad faith business practice."
 type: archive
 source: twitter
 source_url: "https://x.com/rfleury/status/1608285498828636160"
 author: "Ryan Fleury"
 handle: rfleury
 post_id: "1608285498828636160"
 date: 2022-12-29
 archived: 2026-08-27
 draft: false
 tags:
  - archive
  - twitter
  - rfleury
 description: "@AbnerCoimbre @sssmcgrath Ah good, important clarification :) Frankly I wouldn’t care for the project if it wasn’t held up as an important project in the Handmade sphere via avenues like HMS, so I think it’s relevant to distance myself from what I’d call bad faith business practice."
 in_reply_to: ""
 ---
 ## Source
 - URL: https://x.com/rfleury/status/1608285498828636160
 - Author: Ryan Fleury (@rfleury)
 - Posted: 2022-12-29 02:15:18
 ## Thread
 **1/** **@rfleury** ^1608285498828636160
 **@AbnerCoimbre** **@sssmcgrath**
 Ah good, important clarification :) Frankly I wouldn’t care for the project if it wasn’t held up as an important project in the Handmade sphere via avenues like HMS, so I think it’s relevant to distance myself from what I’d call bad faith business practice.
 **2/** **@rfleury** ^1608286249499910145
 **@AbnerCoimbre** **@sssmcgrath**
 Selling a product which asks devs to sacrifice some amount of self-reliance, then later compromising that trust, does an enormous disservice to honest, small, craftsmanship-minded developers.
 https://open.substack.com/pub/ryanfleury/p/ships-icebergs-game-engines
 Branches: [[archive/threads/rfleury/2022-12-29-ah-good-important-clarification-frankly-i-wouldnt/2022-12-29-PLyczkowski-go-open-source]], [[archive/threads/rfleury/2022-12-29-ah-good-important-clarification-frankly-i-wouldnt/2022-12-29-Mythiqke-thanks-for-sharing-this-thats-a-nice-article]]
@@ -18,7 +18,16 @@ tags:
 - [[archive/threads/rfleury/2019-08-29-why-do-we-spend-so-much-effort-to-encode]]
 - [[archive/threads/rfleury/2019-12-23-the-new-4coder-update-beta-4-1-0-has-been-awesome]]
 - [[archive/threads/rfleury/2019-12-26-thread]]
 - [[archive/threads/rfleury/2020-03-04-new-programming-blog-post-about-the-complexity]]
 - [[archive/threads/rfleury/2020-04-06-it-is-unfortunate-that-programmers-are-taught-to]]
 - [[archive/threads/rfleury/2020-05-15-it-is-roughly-2-months-in]]
 - [[archive/threads/rfleury/2020-05-15-to-clarify-the-mouse-controls-are-just-a-small]]
 - [[archive/threads/rfleury/2020-05-22-haha-very-true-in-my-mind-the-preferable-ui-ux]]
 - [[archive/threads/rfleury/2020-10-31-i-dont-think-id-classify-our-goals-one-way-or]]
 - [[archive/threads/rfleury/2021-05-13-https-handmade-network-manifesto]]
 - [[archive/threads/rfleury/2021-07-13-this-github-issue-is-detestable-and-hard-to-read]]
 - [[archive/threads/rfleury/2022-12-13-its-an-incredibly-useful-skill]]
 - [[archive/threads/rfleury/2022-12-29-ah-good-important-clarification-frankly-i-wouldnt]]
 - [[archive/threads/rfleury/2024-12-18-one-of-the-most-powerful-lessons-i-learned-as-a]]
 - [[archive/threads/rfleury/2025-04-30-to-the-degree-this-is-true-its-only-in-a]]
 - [[archive/threads/rfleury/2025-10-10-new-post-multi-core-by-default]]