4 ms·

> There are and have been many techniques and projects for making C more memory-safe. Sort of. None of them got all the way to safety, or they never got all th

> There are and have been many techniques and projects for making C more memory-safe. Sort of. None of them got all the way to safety, or they never got all the way to compatibility with C. Fil-C is novel in that it achieves both safety and compatibility. > The crucial question it always comes down to is what performance hit do you take using them? Is that really the crucial question? I don't think you would have even gotten to asking that question with most attempts to make C memory safe, because they involved experimental academic compilers that could only compile a subset of the language and only worked for a tiny corpus of benchmarks. Lots of C/C++ code is not written with a perf mindset. Most of the UNIX utilities are like that, for example. > That's why C has been on top for so long. Seat-of-the-pants hand-crafted C has always been the fastest high-level language. I don't think that's the reason. C rose to where it is today even when it was much slower than assembly. C was slower than FORTRAN for a long time (maybe still is?) but people preferred C over FORTRAN anyway. C's biggest superpower is how easy it makes it to talk to system ABI (syscalls, dynamic linking, etc).

blacksqr 2y ago
>> There are and have been many techniques and projects for making C more memory-safe. > Sort of. Yes. That's why I used the qualifier "more." Our statements are not in conflict. > Fil-C is novel in that it achieves both safety and compatibility. How does it affect performance? >> The crucial question it always comes down to is what performance hit do you take using them? > Is that really the crucial question? Yes, because it's the factor that industry leaders use to decide on which language to use. For example, Apple switching from Pascal to C way back in the Stone Age. The fact that it's the crucial question doesn't mean that lots of people don't consider other factors for their own reasons. > I don't think you would have even gotten to asking that question with most attempts to make C memory safe. Yes, most. But for example, Microsoft's Checked C comes with a performance penalty of almost 10% for a partial solution. Not academic. Very commercial. > C rose to where it is today even when it was much slower than assembly Yes, that's why I said "high-level language." I don't consider assembly high-level, do you? > people preferred C over FORTRAN anyway People preferred C in the 1970s/80s because at the time you could allocate memory dynamically in C but not in FORTRAN. FORTRAN fixed that in the 1990s, but by then there were too few FORTRAN programmers to compete. Since then C has serially defeated all newcomers. Maybe Go or Rust are poised to take it on. When a major operating system switches from C, we'll know.
- pizlonator 2y ago
  > How does it affect performance? Right now, 1.5x-5x, but considering how many optimizations I know I can do but haven't done yet, I think those numbers are an upper bound. > Yes, because it's the factor that industry leaders use to decide on which language to use. For example, Apple switching from Pascal to C way back in the Stone Age. The fact that it's the crucial question doesn't mean that lots of people don't consider other factors for their own reasons. I don't think this is true at all, sorry. Top reason for using C/C++ is inertia. If you've got a pile of C code, then you'll keep writing C. > Yes, most. But for example, Microsoft's Checked C comes with a performance penalty of almost 10% for a partial solution. Checked C didn't make C memory safe, so I don't think it's interesting. > Yes, that's why I said "high-level language." I don't consider assembly high-level, do you? No, I don't consider assembly to be high-level. The point is: serious engineers don't just blindly reach for the fastest programming language. They'll take slow downs if it makes them more productive. Happens all the time. > People preferred C in the 1970s/80s because at the time you could allocate memory dynamically in C but not in FORTRAN. FORTRAN fixed that in the 1990s, but by then there were too few FORTRAN programmers to compete. Since then C has serially defeated all newcomers. Maybe Go or Rust are poised to take it on. When a major operating system switches from C, we'll know. The last time I saw a benchmark of FORTRAN beating C was the early 2000's. FORTRAN is much easier to optimize and compile. C is great for writing operating systems because C has the right abstractions, such as the abstractions necessary for doing dynamic linking and basically any kind of ABI compatibility. Rust and Go don't have that today. Even C++ is worse than C in this regard. Swift has ABI, but it took heroic efforts to get there. C didn't eat the world because of its stellar performance. It's the other way around. C has stellar performance because it ate the world, and then the industry had no choice but to make it fast.

blacksqr 2y ago

>> There are and have been many techniques and projects for making C more memory-safe. > Sort of. Yes. That's why I used the qualifier "more." Our statements are not in conflict. > Fil-C is novel in that it achieves both safety and compatibility. How does it affect performance? >> The crucial question it always comes down to is what performance hit do you take using them? > Is that really the crucial question? Yes, because it's the factor that industry leaders use to decide on which language to use. For example, Apple switching from Pascal to C way back in the Stone Age. The fact that it's the crucial question doesn't mean that lots of people don't consider other factors for their own reasons. > I don't think you would have even gotten to asking that question with most attempts to make C memory safe. Yes, most. But for example, Microsoft's Checked C comes with a performance penalty of almost 10% for a partial solution. Not academic. Very commercial. > C rose to where it is today even when it was much slower than assembly Yes, that's why I said "high-level language." I don't consider assembly high-level, do you? > people preferred C over FORTRAN anyway People preferred C in the 1970s/80s because at the time you could allocate memory dynamically in C but not in FORTRAN. FORTRAN fixed that in the 1990s, but by then there were too few FORTRAN programmers to compete. Since then C has serially defeated all newcomers. Maybe Go or Rust are poised to take it on. When a major operating system switches from C, we'll know.

pizlonator 2y ago
> How does it affect performance? Right now, 1.5x-5x, but considering how many optimizations I know I can do but haven't done yet, I think those numbers are an upper bound. > Yes, because it's the factor that industry leaders use to decide on which language to use. For example, Apple switching from Pascal to C way back in the Stone Age. The fact that it's the crucial question doesn't mean that lots of people don't consider other factors for their own reasons. I don't think this is true at all, sorry. Top reason for using C/C++ is inertia. If you've got a pile of C code, then you'll keep writing C. > Yes, most. But for example, Microsoft's Checked C comes with a performance penalty of almost 10% for a partial solution. Checked C didn't make C memory safe, so I don't think it's interesting. > Yes, that's why I said "high-level language." I don't consider assembly high-level, do you? No, I don't consider assembly to be high-level. The point is: serious engineers don't just blindly reach for the fastest programming language. They'll take slow downs if it makes them more productive. Happens all the time. > People preferred C in the 1970s/80s because at the time you could allocate memory dynamically in C but not in FORTRAN. FORTRAN fixed that in the 1990s, but by then there were too few FORTRAN programmers to compete. Since then C has serially defeated all newcomers. Maybe Go or Rust are poised to take it on. When a major operating system switches from C, we'll know. The last time I saw a benchmark of FORTRAN beating C was the early 2000's. FORTRAN is much easier to optimize and compile. C is great for writing operating systems because C has the right abstractions, such as the abstractions necessary for doing dynamic linking and basically any kind of ABI compatibility. Rust and Go don't have that today. Even C++ is worse than C in this regard. Swift has ABI, but it took heroic efforts to get there. C didn't eat the world because of its stellar performance. It's the other way around. C has stellar performance because it ate the world, and then the industry had no choice but to make it fast.