4 ms·

I’ve never said that Fil-C is better than Rust full stop. I have articulated the specific ways that Fil-C is better. And I’ve articulated the specific ways th

I’ve never said that Fil-C is better than Rust full stop. I have articulated the specific ways that Fil-C is better. And I’ve articulated the specific ways that Rust is better. You’ve enumerated some of those reasons from your perspective, though I disagree on the details. I like those kinds of conversations. We shouldn’t shy away from them as a community. They help us grow a shared understanding of the tech

wild_pointer 3mo ago
Let's not shy away then. What details do you disagree on? P.S. Also fan of your work. Competition is always good.
- pizlonator 3mo ago
  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: > it does not free the developer from the difficulty of having to manually write memory-safe C code; their program will just crash if they get it wrong. When I write new code in Fil-C, I just lean into the GC all the way, which makes programming in C and C++ so much nicer. I don’t ref count, I don’t use smart pointers, I don’t free and I don’t delete. It makes these languages so much nicer! Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly means I spend basically zero time debugging memory safety issues. The reliability of the failures totally changes the dev experience for the better. That’s subjective obviously. Some folks swear by type systems like Rust’s to catch as many issues as possible. That’s just not how I roll. All of that said - the reason to use rust and not Fil-C is performance and memory usage. Fil-C isn’t there yet, except for maybe a small handful of cases (like BLAKE3 and xzutils, where the overhead is basically zero for some reason … we’ll probably because I did a lot of compiler opts and sometimes you get lucky and they sort of all hit)
  - quotemstr 3mo ago
    > Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly Fil-C as currently implemented does not guarantee panics on unsafe accesses due to races. You dodge the problem by using a private definition of safety under data race that permits program executions nobody would expect.
    - pizlonator 3mo ago
      I define memory safety in terms of capabilities, which is a mainstream definition. The worst that can happen in a race is that you read or write an object that would have been accessible even in the absence of races. The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C
      - mirashii 3mo ago
        I’m having a hard time understanding how these two things can be true at once. Just because the capability exists that somewhere in my program a valid pointer to a piece of memory might exist (what I understand accessible to mean), doesn’t mean that a particular write to that memory location under a data race that tears a pointer is valid. The data race may make a pointer that would never algorithmically appear in the program in the absence of races, and thus make writes that invalidate invariants that should have been preserved. It seems to me this still provides a way to corrupt memory in a difficult to debug way just like C. Am I missing something?
        mirashii 3mo ago
        I've spent some more time over the last day looking at Fil-C more closely, and come to the conclusion that this: > The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C is just blatantly false. It's almost as easy to corrupt memory in Fil-C as it is in C. Type confusion is still allowed. You can still do out of bounds buffer reads/writes as long as they fall within an allocation, so any intra-object stuff, as you might get in common packet or binary file parsing, is still about as unsafe as it was before.

wild_pointer 3mo ago

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

pizlonator 3mo ago
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: > it does not free the developer from the difficulty of having to manually write memory-safe C code; their program will just crash if they get it wrong. When I write new code in Fil-C, I just lean into the GC all the way, which makes programming in C and C++ so much nicer. I don’t ref count, I don’t use smart pointers, I don’t free and I don’t delete. It makes these languages so much nicer! Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly means I spend basically zero time debugging memory safety issues. The reliability of the failures totally changes the dev experience for the better. That’s subjective obviously. Some folks swear by type systems like Rust’s to catch as many issues as possible. That’s just not how I roll. All of that said - the reason to use rust and not Fil-C is performance and memory usage. Fil-C isn’t there yet, except for maybe a small handful of cases (like BLAKE3 and xzutils, where the overhead is basically zero for some reason … we’ll probably because I did a lot of compiler opts and sometimes you get lucky and they sort of all hit)
- quotemstr 3mo ago
  > Also, Fil-C’s guarantee that it will panic on OOB or if a race goes badly Fil-C as currently implemented does not guarantee panics on unsafe accesses due to races. You dodge the problem by using a private definition of safety under data race that permits program executions nobody would expect.
  - pizlonator 3mo ago
    I define memory safety in terms of capabilities, which is a mainstream definition. The worst that can happen in a race is that you read or write an object that would have been accessible even in the absence of races. The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C
    - mirashii 3mo ago
      I’m having a hard time understanding how these two things can be true at once. Just because the capability exists that somewhere in my program a valid pointer to a piece of memory might exist (what I understand accessible to mean), doesn’t mean that a particular write to that memory location under a data race that tears a pointer is valid. The data race may make a pointer that would never algorithmically appear in the program in the absence of races, and thus make writes that invalidate invariants that should have been preserved. It seems to me this still provides a way to corrupt memory in a difficult to debug way just like C. Am I missing something?
      - mirashii 3mo ago
        I've spent some more time over the last day looking at Fil-C more closely, and come to the conclusion that this: > The thing that makes races hard to debug in C or C++ is memory corruption; that doesn’t happen in Fil-C is just blatantly false. It's almost as easy to corrupt memory in Fil-C as it is in C. Type confusion is still allowed. You can still do out of bounds buffer reads/writes as long as they fall within an allocation, so any intra-object stuff, as you might get in common packet or binary file parsing, is still about as unsafe as it was before.