>> 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.
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.
> 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.