3 ms·

> Here's the difference with Fil-C: It's totally memory safe and fanatically compatible with C/C++, no B.S. The other approaches tend to either create a differe

by lmm 2y ago

> Here's the difference with Fil-C: It's totally memory safe and fanatically compatible with C/C++, no B.S. The other approaches tend to either create a different language (not compatible), or tend to create a superset of C/C++ with a safe subset (not totally memory safe, only compatible in the sense that unsafe code continues to be unsafe), or just don't fully square the circle (for example SoftBound could have gotten to full compatibility and safety, but the implementation just didn't). That's exactly the kind of thing that the boosters of all those previous efforts said. But somehow it never quite worked out.

jandrewrogers 2y ago
Also, it always had a material performance impact. People write C++, and to a lesser extent C, because they really, really care about performance. If they didn’t care about performance there are easier languages to use.
- pizlonator 2y ago
  Talking about performance impact is missing the bigger picture of how languages become performant. "Really really care about performance" describes some C/C++ programmers, but definitely not all of them. Finally, Fil-C is already faster than a lot of other safe languages (definitely faster than TypeScript, yet lots of stuff ships in TypeScript). Language implementations get faster over time and young ones tend to be slow. The Fil-C implementation is young. So were all of the previous attempts at memory-safe C - usually an implementation that had years of at most a few person years of investment (because it was done in an academic setting). Young implementations tend to be slow because the optimization investment hasn't happened in anger. So, "past academic attempts were slow" is not a great reason to avoid investigating memory safe C. Performance focus is not the reason why all of the world's C/C++ code gets written. Maybe that's even a minority reason. Lots of stuff uses C/C++ because of reasons like: - It started out in C/C++ so it continues to be in C/C++. So many huge projects are in this boat. - You're critically relying on a library whose only bindings are in C/C++, or the C/C++ bindings are the most mature, or the most easy to use. - You're doing low-level systems stuff, and having pointers that you can pass to syscalls is a core part of your logic. - You want to play nice with the dynamic linking situation on the OS you're targeting. (C/C++ get dynamic linking right in a way other languages don't.) I'd guess less than half of the C/C++ code that's being written today is being written because the programmer was thinking "oh man, this'll be too slow in any other language". Finally, Fil-C is already faster than a lot of memory safe languages. It's just not as fast as Yolo-C, but I don't think you can safely bet that this will be true forever.
pizlonator 2y ago
> That's exactly the kind of thing that the boosters of all those previous efforts said. But somehow it never quite worked out. No, they really didn't. Let's review some of the big cases. - SafeC: not based on a mainstream C compiler, so can't handle gcc/clang extensions (Fil-C can). Had no story for threads or shared memory (Fil-C does). Hence, not really compatible. - CCured: incompatible (cannot compile C code with it without making changes, or running their tool that tries to automate the changes - but even then, common C idioms like unions don't quite work). Didn't use a major C compiler, - SoftBound: not totally memory safe (no attempt to provide safety for linking or function calls). But at least it's highly compatible. I can list more examples. Fil-C is the first to get both compatibility and safety right.
- lmm 2y ago
  > Fil-C is the first to get both compatibility and safety right. Has any impartial third party reached that conclusion? Because honestly the way I remember it everyone says this kind of thing when it's their own project, a lot of the people behind these previous efforts were just as confident as you are.
  - pizlonator 2y ago
    Not in any official capacity but it’s been looked at by other C compiler experts, other programming language experts, GC experts, and security experts. Folks who have looked at it deeply agree with those claims. And I hope they would have told me if they didn’t believe anything about my claims!
achierius 2y ago
> That's exactly the kind of thing that the boosters of all those previous efforts said I don't think this is true. - D, Swift, Rust, Zig: different languages, and while they do have FFI, using it means you're only as safe as your C code - CHERI: requires hardware support to be practical - Checked C, CCured, ?SAFECode IIRC?: too expensive - AddrSan@runtime, ARM MTE, SoftBound: mitigations with too many holes I don't know of many (to be honest, can't think of any) other serious attempts at making a system that tries to cover all three of A) lets you write normal C B) covers all the gaps C) doesn't kill performance
- pizlonator 2y ago
  Well I've got 2/3 so far! Maybe 3/3 depending on your workload and definition of "killing performance". It's less than 2x slower for some stuff. The good news is Fil-C is getting faster all the time, and there are still so many obvious optimizations that I haven't gotten around to.
- Nathanba 2y ago
  I don't get it, what's the catch? Why isn't everyone using Fil-C immediately everywhere?
  - pizlonator 2y ago
    Lots of reasons. Here's one: even just switching from gcc or msvc to clang, in projects that really want to, takes years. Here's another one: the Fil-C compiler is really young, so it almost certainly still has bugs. Those compilers that folks actually use in anger tend to get qualified on ~billions of lines of code before anyone other than the compiler devs touches them. The Fil-C compiler is too young to have that level of qualification. So "immediately everywhere" isn't going to happen. At best it'll be "over a period of time and incrementally".
  - throwaway4655 2y ago
    Awful performance. Usually 2x worse than C and 4x worse in the worst case. Given the comment by Fil-C's creator minimizing the performance issue [0], I wouldn't get my hopes up. [0] https://news.ycombinator.com/item?id=43190938 https://news.ycombinator.com/item?id=43190938

by lmm 2y ago

jandrewrogers 2y ago

Also, it always had a material performance impact. People write C++, and to a lesser extent C, because they really, really care about performance. If they didn’t care about performance there are easier languages to use.

pizlonator 2y ago
Talking about performance impact is missing the bigger picture of how languages become performant. "Really really care about performance" describes some C/C++ programmers, but definitely not all of them. Finally, Fil-C is already faster than a lot of other safe languages (definitely faster than TypeScript, yet lots of stuff ships in TypeScript). Language implementations get faster over time and young ones tend to be slow. The Fil-C implementation is young. So were all of the previous attempts at memory-safe C - usually an implementation that had years of at most a few person years of investment (because it was done in an academic setting). Young implementations tend to be slow because the optimization investment hasn't happened in anger. So, "past academic attempts were slow" is not a great reason to avoid investigating memory safe C. Performance focus is not the reason why all of the world's C/C++ code gets written. Maybe that's even a minority reason. Lots of stuff uses C/C++ because of reasons like: - It started out in C/C++ so it continues to be in C/C++. So many huge projects are in this boat. - You're critically relying on a library whose only bindings are in C/C++, or the C/C++ bindings are the most mature, or the most easy to use. - You're doing low-level systems stuff, and having pointers that you can pass to syscalls is a core part of your logic. - You want to play nice with the dynamic linking situation on the OS you're targeting. (C/C++ get dynamic linking right in a way other languages don't.) I'd guess less than half of the C/C++ code that's being written today is being written because the programmer was thinking "oh man, this'll be too slow in any other language". Finally, Fil-C is already faster than a lot of memory safe languages. It's just not as fast as Yolo-C, but I don't think you can safely bet that this will be true forever.

pizlonator 2y ago

> That's exactly the kind of thing that the boosters of all those previous efforts said. But somehow it never quite worked out. No, they really didn't. Let's review some of the big cases. - SafeC: not based on a mainstream C compiler, so can't handle gcc/clang extensions (Fil-C can). Had no story for threads or shared memory (Fil-C does). Hence, not really compatible. - CCured: incompatible (cannot compile C code with it without making changes, or running their tool that tries to automate the changes - but even then, common C idioms like unions don't quite work). Didn't use a major C compiler, - SoftBound: not totally memory safe (no attempt to provide safety for linking or function calls). But at least it's highly compatible. I can list more examples. Fil-C is the first to get both compatibility and safety right.

lmm 2y ago
> Fil-C is the first to get both compatibility and safety right. Has any impartial third party reached that conclusion? Because honestly the way I remember it everyone says this kind of thing when it's their own project, a lot of the people behind these previous efforts were just as confident as you are.
- pizlonator 2y ago
  Not in any official capacity but it’s been looked at by other C compiler experts, other programming language experts, GC experts, and security experts. Folks who have looked at it deeply agree with those claims. And I hope they would have told me if they didn’t believe anything about my claims!

achierius 2y ago

> That's exactly the kind of thing that the boosters of all those previous efforts said I don't think this is true. - D, Swift, Rust, Zig: different languages, and while they do have FFI, using it means you're only as safe as your C code - CHERI: requires hardware support to be practical - Checked C, CCured, ?SAFECode IIRC?: too expensive - AddrSan@runtime, ARM MTE, SoftBound: mitigations with too many holes I don't know of many (to be honest, can't think of any) other serious attempts at making a system that tries to cover all three of A) lets you write normal C B) covers all the gaps C) doesn't kill performance

pizlonator 2y ago
Well I've got 2/3 so far! Maybe 3/3 depending on your workload and definition of "killing performance". It's less than 2x slower for some stuff. The good news is Fil-C is getting faster all the time, and there are still so many obvious optimizations that I haven't gotten around to.
Nathanba 2y ago
I don't get it, what's the catch? Why isn't everyone using Fil-C immediately everywhere?
- pizlonator 2y ago
  Lots of reasons. Here's one: even just switching from gcc or msvc to clang, in projects that really want to, takes years. Here's another one: the Fil-C compiler is really young, so it almost certainly still has bugs. Those compilers that folks actually use in anger tend to get qualified on ~billions of lines of code before anyone other than the compiler devs touches them. The Fil-C compiler is too young to have that level of qualification. So "immediately everywhere" isn't going to happen. At best it'll be "over a period of time and incrementally".
- throwaway4655 2y ago
  Awful performance. Usually 2x worse than C and 4x worse in the worst case. Given the comment by Fil-C's creator minimizing the performance issue [0], I wouldn't get my hopes up. [0] https://news.ycombinator.com/item?id=43190938 https://news.ycombinator.com/item?id=43190938