| 20 Mar 2026 |
 emily | (and some of the obvious designs are broken) | 12:49:43 |
| emily | that's the part that's not for the faint of heart (but ofc not impossible). in particular though you can run into tradeoffs between the structure of your GC algorithm and how easy it is to use in Rust remotely ergonomically | 12:50:39 |
| emily | (e.g. a moving collector is certainly a bit rough and brings its own constraints, though those aren't particularly fun to interface with in C++ either) | 12:51:18 |
 piegames | In reply to @emilazy:matrix.org
did you read the blog post? :) Years ago | 12:52:17 |
|  @draupnir:lix.systems left the room. | 13:21:43 |
|  Patrick changed their display name from patrickdag to Patrick. | 14:52:31 |
 @rosssmyth:matrix.org | There is memory management toolkit
https://www.mmtk.io/ | 16:25:53 |
 raitobezarius (DECT: 7248) | (yeah lix people looked at it a couple of times) | 16:26:26 |
| 21 Mar 2026 |
 ShalokShalom | There is also https://fil-c.org/ | 12:32:23 |
| piegames | Fil-C is awesome | 12:42:59 |
| piegames | Except that memory safety is not our main problem with C++ | 12:43:37 |
 K900 | I do wonder if cppnix built with fil-c would be 10x slower or less somehow | 13:10:06 |
| ShalokShalom | I read that compiled stuff becomes significantly slower, and that people use it to detect the issues, and not to run it it production. | 13:11:03 |
| ShalokShalom | What is? | 13:11:18 |
| raitobezarius (DECT: 7248) | Fil-C is not memory safe | 13:13:45 |
| raitobezarius (DECT: 7248) | Don't see any interest in that thing | 13:14:21 |
| piegames | In reply to @shalokshalom:kde.org
What is? Ergonomics, developer experience, stdlib | 13:15:45 |
 aloisw | It isn't? Memory safety is basically their headline claim … | 13:16:04 |
| piegames | Like, have you tried writing C++ code? C++ iterators are a work of madness | 13:16:32 |
 Qyriad | ^^^^^ | 13:18:14 |
| raitobezarius (DECT: 7248) | it doesn't solve data races, it doesn't any sort of reasoning over mutable aliasing | 13:18:16 |
| raitobezarius (DECT: 7248) | it has a spatial safety instrumentation pass to clang (so out of band accesses) | 13:18:36 |
| raitobezarius (DECT: 7248) | a runtime support library and a concurrent GC for temporal safety | 13:18:45 |
| Qyriad | Writing production C++ is like writing production Bash. It is extremely difficult to write Correct C++ code and it is extremely difficult to debug | 13:19:02 |
| raitobezarius (DECT: 7248) | "memory safe, bounds checked, GCed ahead-of-time languages" (in the sense Fil-C claim to be) have been existing for a long time | 13:19:26 |
| raitobezarius (DECT: 7248) | * it doesn't solve data races, it doesn't do any sort of reasoning over mutable aliasing | 13:20:12 |
| aloisw | "Doesn't solve data races" in the C "they are still undefined behaviour" sense or in the Java "you may get weird values, but nothing bad happens otherwise" sense? | 13:31:10 |
| raitobezarius (DECT: 7248) | still UB | 13:32:07 |
| raitobezarius (DECT: 7248) | anything that atomically updates a pointer must use the LLVM IR atomics in Fil-C | 13:32:26 |
| raitobezarius (DECT: 7248) | (and so if you store a pointer in one thread and load in another, you may have tearing betwen the addr and caps parts of that pointer) | 13:32:58 |
