5 ms·

With you want 100% compatibility with GNU Coreutils + memory safety just compile Coreutils with Fil-C. 100% compatibility with 0 rewrite.

by akagusu 10mo ago

bfrog 10mo ago
Is Fil-C free of runtime overhead?
- f_devd 10mo ago
  No, it's gc-like. Up to 4x slowdown iirc
  - westurner 10mo ago
    To better port C to Rust: 3C (Checked C), c2rust, Crown ownership analysis, RustMap, c2saferrust (LLM), Laertes
- testdelacc1 10mo ago
  The run time overhead is 2-4x.
  - bfrog 10mo ago
    Isn't this putting it in the Java territory?
    - testdelacc1 10mo ago
      Yeah, pretty much. If someone is ok with a 3-4x slower program with higher memory consumption, that’s great if it saves you development time. But I can’t see someone starting a new project in Fil-C when more performant and ergonomic options exist - Java, C#, Go, Swift, Rust. Even Javascript.
bitbasher 10mo ago
The problem is in the unknowns. The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. The unknowns in a Rust implementation means a crash/denial of service. I know which I prefer.
- yjftsjthsd-h 10mo ago
  > The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. In Fil-C?
  - lucyjojo 10mo ago
    isnt it x86_64 exclusive?
    - yjftsjthsd-h 10mo ago
      https://github.com/pizlonator/fil-c?tab=readme-ov-file#requirements https://github.com/pizlonator/fil-c?tab=readme-ov-file#requi... says that the current implementation only targets Linux+x86_64 but that they see no reason it couldn't be portable. But you're in the wrong (sub)thread; this (sub)thread is about whether it's safe.
      - lucyjojo 10mo ago
        ah, sorry about that and thanks for the link
- stefan_ 10mo ago
  There is no "arbitrary code execution and all kinds of nasty" in the Fil-C version and it profits from the decades spent fixing all the logic bugs, races, environment variable mess in coreutils. Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1 https://ubuntu.com/security/notices/USN-7867-1
josephg 10mo ago
In the short term, yeah 4x slower coreutils is probably worth it for memory safe code. In the long run, I’m glad rust coreutils is slowly working through these compatibility issues so we don’t have to pay for memory safety. Yeah, it'll have new bugs. And right now it’s slightly incompatible. But give it a few more years to cook. I’m sure they’ll get there. As an aside, I find it weird how much negativity rewrites like this get. If someone decided to make a new web browser, C compiler or kernel people would be congratulating them. I really don’t understand the conservatism when it comes to Linux. Is the current implementation perfect? Should it be preserved in amber? The gnu runtime seems like a messy, badly specified hairball of hacky, inconsistent scripts to me. Some guys in a certain room in the 70s and 80s wrote some C programs. And now every bad idea they had lives in perpetuity in my /usr/bin directory? In the decades since, these tools have sprouted hundreds of weird features that almost nobody uses. And now what, people care what language it’s all written in? This code must never be changed?? Who cares.
- wavemode 10mo ago
  > 4x slower coreutils I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The exception would probably be, the hashing utilities like md5sum.)
  - stefan_ 10mo ago
    I tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)
    - josephg 10mo ago
      Why would it be faster? That seems suspicious to me. Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that are only available on newer CPU targets.
      - 0cf8612b2e1e 10mo ago

With you want 100% compatibility with GNU Coreutils + memory safety just compile Coreutils with Fil-C. 100% compatibility with 0 rewrite.

by akagusu 10mo ago

With you want 100% compatibility with GNU Coreutils + memory safety just compile Coreutils with Fil-C. 100% compatibility with 0 rewrite.

bfrog 10mo ago

Is Fil-C free of runtime overhead?

f_devd 10mo ago
No, it's gc-like. Up to 4x slowdown iirc
- westurner 10mo ago
  To better port C to Rust: 3C (Checked C), c2rust, Crown ownership analysis, RustMap, c2saferrust (LLM), Laertes
testdelacc1 10mo ago
The run time overhead is 2-4x.
- bfrog 10mo ago
  Isn't this putting it in the Java territory?
  - testdelacc1 10mo ago
    Yeah, pretty much. If someone is ok with a 3-4x slower program with higher memory consumption, that’s great if it saves you development time. But I can’t see someone starting a new project in Fil-C when more performant and ergonomic options exist - Java, C#, Go, Swift, Rust. Even Javascript.

bitbasher 10mo ago

The problem is in the unknowns. The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. The unknowns in a Rust implementation means a crash/denial of service. I know which I prefer.

yjftsjthsd-h 10mo ago
> The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. In Fil-C?
- lucyjojo 10mo ago
  isnt it x86_64 exclusive?
  - yjftsjthsd-h 10mo ago
    https://github.com/pizlonator/fil-c?tab=readme-ov-file#requirements https://github.com/pizlonator/fil-c?tab=readme-ov-file#requi... says that the current implementation only targets Linux+x86_64 but that they see no reason it couldn't be portable. But you're in the wrong (sub)thread; this (sub)thread is about whether it's safe.
    - lucyjojo 10mo ago
      ah, sorry about that and thanks for the link
stefan_ 10mo ago
There is no "arbitrary code execution and all kinds of nasty" in the Fil-C version and it profits from the decades spent fixing all the logic bugs, races, environment variable mess in coreutils. Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1 https://ubuntu.com/security/notices/USN-7867-1

josephg 10mo ago

In the short term, yeah 4x slower coreutils is probably worth it for memory safe code. In the long run, I’m glad rust coreutils is slowly working through these compatibility issues so we don’t have to pay for memory safety. Yeah, it'll have new bugs. And right now it’s slightly incompatible. But give it a few more years to cook. I’m sure they’ll get there. As an aside, I find it weird how much negativity rewrites like this get. If someone decided to make a new web browser, C compiler or kernel people would be congratulating them. I really don’t understand the conservatism when it comes to Linux. Is the current implementation perfect? Should it be preserved in amber? The gnu runtime seems like a messy, badly specified hairball of hacky, inconsistent scripts to me. Some guys in a certain room in the 70s and 80s wrote some C programs. And now every bad idea they had lives in perpetuity in my /usr/bin directory? In the decades since, these tools have sprouted hundreds of weird features that almost nobody uses. And now what, people care what language it’s all written in? This code must never be changed?? Who cares.

wavemode 10mo ago
> 4x slower coreutils I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The exception would probably be, the hashing utilities like md5sum.)
- stefan_ 10mo ago
  I tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)
  - josephg 10mo ago
    Why would it be faster? That seems suspicious to me. Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that are only available on newer CPU targets.
    - 0cf8612b2e1e 10mo ago