4 ms·

> developed in the 1970s. It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, alon

> developed in the 1970s. It was born in the 1970s and was standardized in the 80s and 90s. It continues to develop. Numerous data types have been added, along with unicode and threads. The C23 standard was released last year.

antonvs 1y ago
You can say something similar about COBOL and FORTRAN. C's fundamental flaws aren't being fixed, because that would require a new language. There comes a point at which it becomes necessary to move on.
- Spivak 1y ago
  What in your mind are the fundamental issues of C? Because memory safety clearly isn't one of them as brand new systems languages are being written without it (Zig).
  - steveklabnik 1y ago
    Absolutely zero shade to Zig, because it is still pre-1.0, but if you look at which new systems languages have gained wide adoption recently, instead of languages that are just created, you end up with Rust. And the stated reason industry is adopting it is memory safety.
    - rc00 1y ago
      What adoption? Blog posts? Echo chambers? Rust peaked. The hype pushers don't want to believe it but that is the reality. Absolutely zero shade to Rust.
      - deleted 1y ago
        [deleted]
  - deleted 1y ago
    [deleted]
  - cwood-sdf 1y ago
    zig is trying its best to also be memory safe (at runtime, if you want it) whereas c is stuck in the past (you can add on sanitizers, but they arent built into the language)
  - antonvs 1y ago
    Memory safety is certainly a pretty fundamental problem with C. Zig actually addresses some of those issues, even if it's not fully "memory safe" by definition. Besides, the fact that new systems languages are being written without memory safety doesn't make it a good idea. People write all sorts of languages for all sorts of reasons. C's lack of memory safety covers a broad range of concerns, including manual memory management, unrestricted pointers, null pointers (Tony Hoare's "billion dollar mistake"), buffer overflows, use-after-free, integer promotions, and so on. Its weak type system is another fundamental limitation, closely related to its limited support for abstraction. The weakness of the standard library reflects this. The weak type system means that the static guarantees it provides are minimal. There were excuses for all this in 1975, there aren't any more. Undefined behavior is more of an issue in C than in most languages. Again, not something you ideally want in a systems language. Language-level concurrency support is virtually nonexistent. Use of textual preprocessing, with limited semantic integration, as a language feature. Aside from the effects on the meaning of source code, it also makes building C programs more complex. And again, the reason C23 hasn't addressed any of this significantly is because of fundamental limitations in the nature of the language. You can't "fix" these things without developing a new language.
    - uecker 1y ago
      I think this narrative of the unfixable fundamental flaws in C is a lot of nonsense. There are certainly a lot of dangerous aspects, but most are rather easily avoided. Rust has an advantage, with temporal memory safety. I do not think C++, Zig, or Go have a fundamental advantage. There is certainly a lot of bad C code out, but instead of changing language, you could also just write modern C code.
      - antonvs 1y ago
        > There are certainly a lot of dangerous aspects, but most are rather easily avoided. This is an almost childish claim. If they're so easily avoided, how do you explain the enormously long list of CVEs for C and C++ programs? > I do not think C++, Zig, or Go have a fundamental advantage. We agree on that. They objectively do not. They're all an attempt to continue the C legacy. Go specifically is particularly ridiculous, having been designed quite recently by people from the 1970s who steadfastly refused to learn any lessons from the last 50 years of programming language development. To be clear: I'm from the 1970s as well. I learned FORTRAN in 1977. But unlike the designers of Go, I didn't allow my understanding of programming language design to stagnate in the 1970s. I learned things. I studied things. I discovered things. Do you believe that C is the ultimate in system programming language design? If you agree that it's not, then what are we arguing about exactly?
- donkeybeer 1y ago
  What's wrong with FORTRAN?
  - pklausler 1y ago
    It’s hard to actually define what Fortran means. There’s features in the standard that are not portable, and many portable features that are not standard. It’s kind of a mess, and getting worse.
    - spauldo 1y ago
      FORTRAN means what it's always meant. The standard is a guide for the implementor. The user needs to code to the implementation. It's a different way of thinking about languages than most people usually do, but it's been true for FORTRAN since the 1950s and is true to some extent of every language with multiple implementations today.
      - pklausler 1y ago
        You support my point while also missing it.
        spauldo 1y ago
        No, I'm disagreeing with you that it's getting worse, as well as that it's all that bad in the first place.
  - antonvs 1y ago
    The same kinds of things that are wrong with all languages originally designed more than 50 years ago (75 years in Fortran's case) and that have accreted features since then. You end up with long-term fads like class-based object orientation embedded in the language, and that inhibits them evolving towards more principled designs. C++ is in a similar situation. All of these languages are Turing complete. So ultimately, if you're happy writing code in some language and don't want to change, that's your choice. But the reason Fortran or C or C++ isn't many people's first choice for new projects are closely related to the reasons I've mentioned. There will always be people who want to stick to what they know, but it's not only science that advances one funeral at a time.

antonvs 1y ago

You can say something similar about COBOL and FORTRAN. C's fundamental flaws aren't being fixed, because that would require a new language. There comes a point at which it becomes necessary to move on.

Spivak 1y ago
What in your mind are the fundamental issues of C? Because memory safety clearly isn't one of them as brand new systems languages are being written without it (Zig).
- steveklabnik 1y ago
  Absolutely zero shade to Zig, because it is still pre-1.0, but if you look at which new systems languages have gained wide adoption recently, instead of languages that are just created, you end up with Rust. And the stated reason industry is adopting it is memory safety.
  - rc00 1y ago
    What adoption? Blog posts? Echo chambers? Rust peaked. The hype pushers don't want to believe it but that is the reality. Absolutely zero shade to Rust.
    - deleted 1y ago
      [deleted]
- deleted 1y ago
  [deleted]
- cwood-sdf 1y ago
  zig is trying its best to also be memory safe (at runtime, if you want it) whereas c is stuck in the past (you can add on sanitizers, but they arent built into the language)
- antonvs 1y ago
  Memory safety is certainly a pretty fundamental problem with C. Zig actually addresses some of those issues, even if it's not fully "memory safe" by definition. Besides, the fact that new systems languages are being written without memory safety doesn't make it a good idea. People write all sorts of languages for all sorts of reasons. C's lack of memory safety covers a broad range of concerns, including manual memory management, unrestricted pointers, null pointers (Tony Hoare's "billion dollar mistake"), buffer overflows, use-after-free, integer promotions, and so on. Its weak type system is another fundamental limitation, closely related to its limited support for abstraction. The weakness of the standard library reflects this. The weak type system means that the static guarantees it provides are minimal. There were excuses for all this in 1975, there aren't any more. Undefined behavior is more of an issue in C than in most languages. Again, not something you ideally want in a systems language. Language-level concurrency support is virtually nonexistent. Use of textual preprocessing, with limited semantic integration, as a language feature. Aside from the effects on the meaning of source code, it also makes building C programs more complex. And again, the reason C23 hasn't addressed any of this significantly is because of fundamental limitations in the nature of the language. You can't "fix" these things without developing a new language.
  - uecker 1y ago
    I think this narrative of the unfixable fundamental flaws in C is a lot of nonsense. There are certainly a lot of dangerous aspects, but most are rather easily avoided. Rust has an advantage, with temporal memory safety. I do not think C++, Zig, or Go have a fundamental advantage. There is certainly a lot of bad C code out, but instead of changing language, you could also just write modern C code.
    - antonvs 1y ago
      > There are certainly a lot of dangerous aspects, but most are rather easily avoided. This is an almost childish claim. If they're so easily avoided, how do you explain the enormously long list of CVEs for C and C++ programs? > I do not think C++, Zig, or Go have a fundamental advantage. We agree on that. They objectively do not. They're all an attempt to continue the C legacy. Go specifically is particularly ridiculous, having been designed quite recently by people from the 1970s who steadfastly refused to learn any lessons from the last 50 years of programming language development. To be clear: I'm from the 1970s as well. I learned FORTRAN in 1977. But unlike the designers of Go, I didn't allow my understanding of programming language design to stagnate in the 1970s. I learned things. I studied things. I discovered things. Do you believe that C is the ultimate in system programming language design? If you agree that it's not, then what are we arguing about exactly?
donkeybeer 1y ago
What's wrong with FORTRAN?
- pklausler 1y ago
  It’s hard to actually define what Fortran means. There’s features in the standard that are not portable, and many portable features that are not standard. It’s kind of a mess, and getting worse.
  - spauldo 1y ago
    FORTRAN means what it's always meant. The standard is a guide for the implementor. The user needs to code to the implementation. It's a different way of thinking about languages than most people usually do, but it's been true for FORTRAN since the 1950s and is true to some extent of every language with multiple implementations today.
    - pklausler 1y ago
      You support my point while also missing it.
      - spauldo 1y ago
        No, I'm disagreeing with you that it's getting worse, as well as that it's all that bad in the first place.
- antonvs 1y ago
  The same kinds of things that are wrong with all languages originally designed more than 50 years ago (75 years in Fortran's case) and that have accreted features since then. You end up with long-term fads like class-based object orientation embedded in the language, and that inhibits them evolving towards more principled designs. C++ is in a similar situation. All of these languages are Turing complete. So ultimately, if you're happy writing code in some language and don't want to change, that's your choice. But the reason Fortran or C or C++ isn't many people's first choice for new projects are closely related to the reasons I've mentioned. There will always be people who want to stick to what they know, but it's not only science that advances one funeral at a time.