3 ms·

> Seems like a bad way to pick technology. This is a very sensible way to pick a technology for a government. Having a cool proof of concept, with a bus facto

by pornel 1y ago

> Seems like a bad way to pick technology. This is a very sensible way to pick a technology for a government. Having a cool proof of concept, with a bus factor of 1, and having a solution that countless government agencies can depend on for multi-million-dollar decades-long software projects are very different things. They can't just depend out of the blue on you personally maintaining "Fil's Unbelievable Garbage Collector" for the lifetime of the government's projects. Maybe you believe they could, but it takes way more legwork to give such assurance to a government. They list TRACTOR under projects they've already funded (and crucially, not among solutions they recommend yet). Apply for funding for Fil-C, and if it gets accepted, it'll probably get listed there too. The TRACTOR approach also has higher tolerance to being an experimental project, because it's one-time conversion of C to Rust. It only needs to work once, not continuously for decades. The Rust-lang org is set up to offer serious long-term support, and is way past having a critical dependency on a single developer.

pizlonator 1y ago
> This is a very sensible way to pick a technology for a government. No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C. The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.
- pornel 1y ago
  You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative. For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone. There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.
  - pizlonator 1y ago
    > You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. Says who? Most software written in C is not perf sensitive. My shell could be 4x slower and I wouldn’t care. That’s also true for most of the GUI stuff I use, including the browser. > you've got a more fine-grained ASAN. The difference between Fil-C and asan is that Fil-C is memory safe while asan isn’t. This has nothing to do with “fine grained”. > it's not blowing away the whole narrative. The narrative is that C is not a memory safe language. That narrative is false. If the narrative was, “C is only memory safe if you’re willing to pay perf cost” then like whatever. But that’s not what folks are saying > For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. No there aren’t. Fil-C is the only memory safe solution for C code. Hwasan, mte, etc aren’t memory safe. Asan isn’t memory safe (and probably also isn’t cheaper). Don’t know what else you’re thinking of. > There's already CHERI that takes a similar approach to pointer tagging Neither Cheri nor Fil-C use pointer tagging. Both use pointer capabilities. Fil-C’s capabilities are safer (they actually protect use after free). Fil-C is faster than Cheri because I can run Fil-C on fast commodity hardware. Fil-C in my x86 box is orders of magnitude faster than the fastest Cheri machine ever

by pornel 1y ago

pizlonator 1y ago

> This is a very sensible way to pick a technology for a government. No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C. The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.

pornel 1y ago
You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative. For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone. There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.
- pizlonator 1y ago
  > You've made a language that is at least 20-50% slower than C and has a garbage collector. That's not what people use C for. Says who? Most software written in C is not perf sensitive. My shell could be 4x slower and I wouldn’t care. That’s also true for most of the GUI stuff I use, including the browser. > you've got a more fine-grained ASAN. The difference between Fil-C and asan is that Fil-C is memory safe while asan isn’t. This has nothing to do with “fine grained”. > it's not blowing away the whole narrative. The narrative is that C is not a memory safe language. That narrative is false. If the narrative was, “C is only memory safe if you’re willing to pay perf cost” then like whatever. But that’s not what folks are saying > For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks. No there aren’t. Fil-C is the only memory safe solution for C code. Hwasan, mte, etc aren’t memory safe. Asan isn’t memory safe (and probably also isn’t cheaper). Don’t know what else you’re thinking of. > There's already CHERI that takes a similar approach to pointer tagging Neither Cheri nor Fil-C use pointer tagging. Both use pointer capabilities. Fil-C’s capabilities are safer (they actually protect use after free). Fil-C is faster than Cheri because I can run Fil-C on fast commodity hardware. Fil-C in my x86 box is orders of magnitude faster than the fastest Cheri machine ever