Fil-C: Garbage In, Memory Safety Out [video]

Post by wild_pointer » Sat, Jul 25, 2026, 2:07 PM UTC

pizlonator wrote: post #107

wild_pointer wrote: post #101

Earlier quoted context omitted.

Let's not shy away then. What details do you disagree on? P.S. Also fan of your work. Competition is always good.

Rereading your post, I think I just disagree on two things: I don’t think Rust users can be trivialized into the “two kinds” that you list, and if one of the kinds is “app developer” then I bet you there are apps where Fil-C’s value proposition is exactly right, except just the fact that Fil-C is so new and immature. Say you want to ship a native UI. Using GTK from fil-C is fantastic. And I specifically disagree with…

Post by dundarious » Sat, Jul 25, 2026, 2:33 PM UTC

NobodyNada wrote: post #62

dundarious wrote: post #34

Earlier quoted context omitted.

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks) If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere . Safety is always conditional on the underlying unsafe implementation having no bugs. With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies. So…

Post by wasmperson » Sat, Jul 25, 2026, 3:29 PM UTC

kibwen wrote: post #153

wasmperson wrote: post #71

Earlier quoted context omitted.

The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits: https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...

No, Rust does not have exceptions. Rust has unwinding, if you choose to compile your program with support for it, which you are free not to, and is trivially achieved by a single flag.

  use std::panic::catch_unwind;
  fn throws_exception(){
      panic!("hello");
  }
  fn main(){
      match catch_unwind(|| {
          throws_exception();
          println!("Never reached");
      }) {
          Ok(_) => (),
          Err(e) => println!(
              "threw an exception: {:?}",
              e.downcast_ref::().unwrap())
      }
  }

Post by wasmperson » Sat, Jul 25, 2026, 4:11 PM UTC

uecker wrote: post #120

wasmperson wrote: post #85

Earlier quoted context omitted.

Now it's your example that's too simple. I can't present a counter-example that wouldn't look totally different: if you avoid the indexing operator then trivially incorrect code like that becomes unrepresentable. It's like if I said destructors help you avoid memory leaks and you asked how you'd avoid a leak in a single-function program that does nothing but call `Box::leak()`. Again: I'm not disputing the fact that…

If you agree with that Rust sometimes has to add dynamic bounds check, then you could have just agreed with my original comment.

Post by Panzerschrek » Sat, Jul 25, 2026, 4:24 PM UTC