4 ms·

That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and

by ajarmst 10y ago

That's not really fair. If you go far enough back in the ancestral compiler list on any language, you'll probably hit C. You'll definitely hit hit assembly and bare-metal machine code. Heck, at some point you might run into hand wire-wrapped microcode---but I don't think that's an argument that we should be using it. That's just an artifact of the history of operating system development, and the fact that C spent (is spending) a considerable period as the de facto standard for OS development. That it was first doesn't necessarily make it better. A few events turning out differently in history, and you'd be making the exact same arguments about lisp, BCPL or Fortran.

nickpsecurity 10y ago
It is a weak claim. You'd hit Pascal for a whole family of them with FreePascal well-maintained, fast, and portable. The Wirth ones vary language-by-language. There are BASIC's written in BASIC, LISP's in LISP (or 1940's machine code or microcode), silicon implementations of Java (eg JOP), Hyde's HLA assembly, IBM's PL/S that's still around, Amiga-E in M68K assembly, and Hansen's simpler Edison language in machine code or Pascal one. So, yeah, C wasn't at the bottom of all kinds of past and present developments, many more complex than C. It being at bottom of many current ones is social and economic, not a technical necessity. One could just as easily target FreePascal, a low-level VM w/out C's built-in preferences, or a HLA on a specific ISA.
- qwertyuiop924 10y ago
  I know full well: my point was that you cannot depend on that which you wish to replace: Targeting something that doesn't is a valid approach for doing so.
  - nickpsecurity 10y ago
    Care to elaborate? You can depend on what you want to replace for bootstrapping. You can use tools written in it, compiled with it, or even hand-converted to assembly for first run. That it was a stepping stone doesn't undermine an argument to replace it in general or even say much about it. The common flaw in reasoning is that "If C was used at any point, then C is technically good, essential, or something similar." It can come down to something as simple as author's convenience, personal preference, or even timetable. Using vs replacing a C compiler fits into all three I imagine. :)
    - qwertyuiop924 10y ago
      Okay. Let's imagine Zig does replace C: 20 years from now, nobody uses C, except in a few specialized fields, same as FORTRAN. However, every time somebody has to recompile Zig, they have to go get a C compiler. Furthermore, most people don't know C any more than they know FORTRAN, making the compiler hard to contribute to. I'm not saying C is technically good, or essential, I'm saying that you cannot be dependant on something you want to get rid of, because then you can't get rid of it.
      - AsyncAwait 10y ago
        You have to know that you're making a hugely stretch of an argument, I mean none of the "C replacement" languages really expect to replace C so completely that there will be no more C code written or no C compiler that runs on modern hardware in 20 years - you have to realise that's not what they mean by "replace". It's meant as in "replace for the majority of modern use cases, where the power of C is needed, but a better language is desired" (or some variation thereof) and if it does come to it...meaning a language will replace C so completely that there'll be no C in sight in 20 years time, (hard to believe), then it'll probably be so, because we figured out how to not depend on C and go on without it.
        qwertyuiop924 10y ago
        I don't expect it, but if that's what you're shooting for, that's the sort of thing you've got to contend with. And no, I don't know what they mean by replace, but if they make such a big point of stdlib not depending in cstdlib, what other conclusions am I supposed to draw?
      - nickpsecurity 10y ago
        I think you're missing the whole concept of bootstrapping. C, if only language, would be used to compile the first, Zig compiler. The next compiler, written in Zig, would go through the first one. You then have a pile of machine code that turns Zig into machine code. No C left after the first pass. So, there's no dependency if you're switching languages or getting rid of it. There's just a one-time use. For legacy systems, there's also potential for a source-to-source compiler if semantics are close. There's also binary recompilation and integration into new language a la AS/400 or OpenVMS migrations.
  - Ygg2 10y ago
    That is simply untrue. Replace your example with assembly and C. According to this, C can't replace assembly and assembly can't replace machine code, which is an absurd statement. No modern development of OS is done in assembly only.
    - qwertyuiop924 10y ago
      C didn't fully replace asm Asm is still a language that is used. If we're talking about fully replacing a language, than yes, you cannot have it in your toolchain.
      - Ygg2 10y ago
        Right, and C is widely used/successful language. As a poet once said - "Perfect is the enemy of good". Rust never aimed to replace all of C/C++ forever, everyhwere. That's nigh impossible. Much in the same way, it's impossible for ASM to replace machine code or 386 processors to replace Commodore 64 or Analytical engine. There will always be some shop that programs in ASM/C/C++, like there are shops that program in COBOL. Rust point was - to replace C/C++ in domains that require safety and speed.
        qwertyuiop924 10y ago
        No, Rust didn't. Zig does.
qwertyuiop924 10y ago
True, it's not fair. I didn't say that your first implementation had to be beneath C, but if you really want to replace the language at the bottom of the stack, you have to rewrite the stack. Otherwise, you haven't really replaced it, now have you?
- hueving 10y ago
  No, that's not true. You can replace lots of unsafe C code with safer code even if C is used somewhere in the system. You can decide to stop using dynamite to remove weeds and still use it in mining.
  - qwertyuiop924 10y ago
    But that's not what we're talking about: we're talking about replacing C entirely. You can't outlaw dynamite if it's in use for making the dynamite replacement.
pjmlp 10y ago
Contrary to AT&T preachers there were plenty of languages being used before C. I never used C on the few compilers I worked on.

by ajarmst 10y ago

nickpsecurity 10y ago

It is a weak claim. You'd hit Pascal for a whole family of them with FreePascal well-maintained, fast, and portable. The Wirth ones vary language-by-language. There are BASIC's written in BASIC, LISP's in LISP (or 1940's machine code or microcode), silicon implementations of Java (eg JOP), Hyde's HLA assembly, IBM's PL/S that's still around, Amiga-E in M68K assembly, and Hansen's simpler Edison language in machine code or Pascal one. So, yeah, C wasn't at the bottom of all kinds of past and present developments, many more complex than C. It being at bottom of many current ones is social and economic, not a technical necessity. One could just as easily target FreePascal, a low-level VM w/out C's built-in preferences, or a HLA on a specific ISA.

qwertyuiop924 10y ago
I know full well: my point was that you cannot depend on that which you wish to replace: Targeting something that doesn't is a valid approach for doing so.
- nickpsecurity 10y ago
  Care to elaborate? You can depend on what you want to replace for bootstrapping. You can use tools written in it, compiled with it, or even hand-converted to assembly for first run. That it was a stepping stone doesn't undermine an argument to replace it in general or even say much about it. The common flaw in reasoning is that "If C was used at any point, then C is technically good, essential, or something similar." It can come down to something as simple as author's convenience, personal preference, or even timetable. Using vs replacing a C compiler fits into all three I imagine. :)
  - qwertyuiop924 10y ago
    Okay. Let's imagine Zig does replace C: 20 years from now, nobody uses C, except in a few specialized fields, same as FORTRAN. However, every time somebody has to recompile Zig, they have to go get a C compiler. Furthermore, most people don't know C any more than they know FORTRAN, making the compiler hard to contribute to. I'm not saying C is technically good, or essential, I'm saying that you cannot be dependant on something you want to get rid of, because then you can't get rid of it.
    - AsyncAwait 10y ago
      You have to know that you're making a hugely stretch of an argument, I mean none of the "C replacement" languages really expect to replace C so completely that there will be no more C code written or no C compiler that runs on modern hardware in 20 years - you have to realise that's not what they mean by "replace". It's meant as in "replace for the majority of modern use cases, where the power of C is needed, but a better language is desired" (or some variation thereof) and if it does come to it...meaning a language will replace C so completely that there'll be no C in sight in 20 years time, (hard to believe), then it'll probably be so, because we figured out how to not depend on C and go on without it.
      - qwertyuiop924 10y ago
        I don't expect it, but if that's what you're shooting for, that's the sort of thing you've got to contend with. And no, I don't know what they mean by replace, but if they make such a big point of stdlib not depending in cstdlib, what other conclusions am I supposed to draw?
    - nickpsecurity 10y ago
      I think you're missing the whole concept of bootstrapping. C, if only language, would be used to compile the first, Zig compiler. The next compiler, written in Zig, would go through the first one. You then have a pile of machine code that turns Zig into machine code. No C left after the first pass. So, there's no dependency if you're switching languages or getting rid of it. There's just a one-time use. For legacy systems, there's also potential for a source-to-source compiler if semantics are close. There's also binary recompilation and integration into new language a la AS/400 or OpenVMS migrations.
- Ygg2 10y ago
  That is simply untrue. Replace your example with assembly and C. According to this, C can't replace assembly and assembly can't replace machine code, which is an absurd statement. No modern development of OS is done in assembly only.
  - qwertyuiop924 10y ago
    C didn't fully replace asm Asm is still a language that is used. If we're talking about fully replacing a language, than yes, you cannot have it in your toolchain.
    - Ygg2 10y ago
      Right, and C is widely used/successful language. As a poet once said - "Perfect is the enemy of good". Rust never aimed to replace all of C/C++ forever, everyhwere. That's nigh impossible. Much in the same way, it's impossible for ASM to replace machine code or 386 processors to replace Commodore 64 or Analytical engine. There will always be some shop that programs in ASM/C/C++, like there are shops that program in COBOL. Rust point was - to replace C/C++ in domains that require safety and speed.
      - qwertyuiop924 10y ago
        No, Rust didn't. Zig does.

qwertyuiop924 10y ago

True, it's not fair. I didn't say that your first implementation had to be beneath C, but if you really want to replace the language at the bottom of the stack, you have to rewrite the stack. Otherwise, you haven't really replaced it, now have you?

hueving 10y ago
No, that's not true. You can replace lots of unsafe C code with safer code even if C is used somewhere in the system. You can decide to stop using dynamite to remove weeds and still use it in mining.
- qwertyuiop924 10y ago
  But that's not what we're talking about: we're talking about replacing C entirely. You can't outlaw dynamite if it's in use for making the dynamite replacement.

pjmlp 10y ago

Contrary to AT&T preachers there were plenty of languages being used before C. I never used C on the few compilers I worked on.