5 ms·

> It's more comprehensively safe than Rust Yeah. By adding a runtime. > Fil-C achieves this using a combination of concurrent garbage collection and invisibl

by Ygg2 1y ago

> It's more comprehensively safe than Rust Yeah. By adding a runtime. > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) https://github.com/pizlonator/llvm-project-deluge/tree/deluge https://github.com/pizlonator/llvm-project-deluge/tree/delug...

pizlonator 1y ago
> Yeah. By adding a runtime. So? That doesn't make it any less safe or useful. In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem. Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.
- jandrewrogers 1y ago
  It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.
  - dustbunny 1y ago
    > a lot less performant Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!
    - pizlonator 1y ago
      I mean bro isn’t totally wrong. Fil-C’s perf sucks on some workloads. And it doesn’t suck on others. Extreme examples to give you an idea: - xzutils had about 1.2x overhead. So slower but totally usable. - no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound. - 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think. But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).
  - pizlonator 1y ago
    > It makes it a lot less performant and there is no avoiding or mitigating that downside. You can’t possibly know that. > C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Is that why sudo, bash, coreutils, and ssh are written in C? Of course not. C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI. > Fil-C is not a replacement for C++ generally, that oversells it. I have made no such claim. Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier). > It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy. It’s the opposite in my experience. For example, xzutils and simdutf have super lower overhead in Fil-C. In the case of SIMD code it’s because using SIMD amortizes Fil-C’s overheads.
    - comex 1y ago
      > C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI. Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer. > Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier). The world of compilers is littered with corpses of projects that spent years claiming faster performance was right around the corner. I believe you can make it faster, but how much faster? We'll see. I think these types of compatibility layers will be a great option moving forward for legacy software. But I have a hard time seeing the case for using Fil-C for new code: all the known disadvantages of C and C++, now combined with performance closer to Java than Rust (if not worse), and high difficulty interoperating with other native code (normally C and C++'s strength!), in exchange for marginal safety improvements over Rust (minus Rust's more general safety culture). edit: I feel bad writing such a dismissive comment, but it's hard to avoid reacting that way when I see unrealistically rosy portrayals of projects.

by Ygg2 1y ago

pizlonator 1y ago

> Yeah. By adding a runtime. So? That doesn't make it any less safe or useful. In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem. Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.

jandrewrogers 1y ago
It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.
- dustbunny 1y ago
  > a lot less performant Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!
  - pizlonator 1y ago
    I mean bro isn’t totally wrong. Fil-C’s perf sucks on some workloads. And it doesn’t suck on others. Extreme examples to give you an idea: - xzutils had about 1.2x overhead. So slower but totally usable. - no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound. - 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think. But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).
- pizlonator 1y ago
  > It makes it a lot less performant and there is no avoiding or mitigating that downside. You can’t possibly know that. > C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Is that why sudo, bash, coreutils, and ssh are written in C? Of course not. C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI. > Fil-C is not a replacement for C++ generally, that oversells it. I have made no such claim. Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier). > It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy. It’s the opposite in my experience. For example, xzutils and simdutf have super lower overhead in Fil-C. In the case of SIMD code it’s because using SIMD amortizes Fil-C’s overheads.
  - comex 1y ago
    > C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI. Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer. > Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier). The world of compilers is littered with corpses of projects that spent years claiming faster performance was right around the corner. I believe you can make it faster, but how much faster? We'll see. I think these types of compatibility layers will be a great option moving forward for legacy software. But I have a hard time seeing the case for using Fil-C for new code: all the known disadvantages of C and C++, now combined with performance closer to Java than Rust (if not worse), and high difficulty interoperating with other native code (normally C and C++'s strength!), in exchange for marginal safety improvements over Rust (minus Rust's more general safety culture). edit: I feel bad writing such a dismissive comment, but it's hard to avoid reacting that way when I see unrealistically rosy portrayals of projects.