| 21 Mar 2026 |
 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 | it doesn't solve data races, it doesn't any sort of reasoning over mutable aliasing | 13:18:16 |
| raitobezarius | it has a spatial safety instrumentation pass to clang (so out of band accesses) | 13:18:36 |
| raitobezarius | 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 | "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 | * 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 | still UB | 13:32:07 |
| raitobezarius | anything that atomically updates a pointer must use the LLVM IR atomics in Fil-C | 13:32:26 |
| raitobezarius | (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 |
 K900 | Honestly fil-c is a good sanitizer | 13:33:18 |
| K900 | It's just not any of the things they advertise it as | 13:33:30 |
| raitobezarius | i mean, i understand the demand for these tools and I'm happy someone actually made an implementation of two ideas that have been roaming | 13:33:58 |
| raitobezarius | e.g. https://dl.acm.org/doi/10.1145/1543135.1542504 | 13:34:14 |
| raitobezarius | and uhm https://cheri-alliance.org/ :D | 13:34:23 |
| raitobezarius | (which all are cited by Fil-C to be clear) | 13:34:33 |
| K900 | Also, this is a stupid thing that I should not get this hung up on | 13:34:53 |
| K900 | But naming a programming language after yourself is rancid fucking vibes | 13:35:04 |
| raitobezarius | I think it would help too if the author was not claiming things like Fil-C is safer than Rust | 13:36:23 |
| raitobezarius | here's a concrete example I found again about this: https://gist.github.com/unixpickle/4eaae977d79c3b9eeda45d5baf52859f | 13:36:53 |
| raitobezarius | tbh, according to that definition of (memory?) safety, Golang is also not safe | 13:39:21 |
| raitobezarius | c.f. https://github.com/StalkR/misc/blob/master/go/race-slice.go | 13:39:34 |
| aloisw | Data race is still full UB in Go? | 13:41:01 |
| K900 | Yes | 13:41:35 |
 KFears& 🏳️⚧️ (they/them) | In reply to @k900:0upti.me
But naming a programming language after yourself is rancid fucking vibes Honestly immediate black flag | 13:42:44 |
| KFears& 🏳️⚧️ (they/them) | Name one language named after a person where the person isn't a massive dick | 13:43:02 |
