| 20 Mar 2026 |
 emily | cxx binds directly to the Rust | 12:33:32 |
 Sergei Zimmerman (xokdvium) | In reply to @xokdvium:matrix.org
Can’t you compile the C++ part to llvm it with C ABI and link that with the rust shim? (That’s also compiled down to llvm-ir) | 12:33:32 |
| emily | but yes you can LTO between the two languages | 12:33:40 |
| emily | the Rust toolchain has specific support for it | 12:34:00 |
| Sergei Zimmerman (xokdvium) | Well fat lto is basically just linking llvm ir modules together, right? | 12:34:06 |
| emily | yeah | 12:34:13 |
| emily | but you can do cross language thinlto too | 12:34:21 |
| emily | https://doc.rust-lang.org/rustc/linker-plugin-lto.html | 12:35:14 |
| emily | (for clarity: cxx is a Rust crate. it just layers on top of native C FFI in Rust to bind to C++) | 12:37:56 |
| emily | (incl interop with C++ smart pointers etc.) | 12:38:14 |
| emily | (also for clarity: not just because you can get it wrong although that would be sufficient by itself, but also because even if you get recording the actual roots right it's quite likely that what you're telling the compiler with the resulting API shape will allow it to make assumptions that can lead to UB crashes) | 12:42:49 |
 piegames | I mean, envision this: A special wrapper type which handles the manual root declaration, together with a special constructor and a macro that ensure the only way to get such a value is pinned on the stack. I'm daydreaming here, but doesn't sound completely implausible | 12:46:33 |
| emily | did you read the blog post? :) | 12:49:07 |
| emily | you can do safe rooting APIs. it's just hard | 12:49:23 |
| 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 | (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 | Fil-C is not memory safe | 13:13:45 |
| raitobezarius | Don't see any interest in that thing | 13:14:21 |
