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.
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.
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.
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. :)
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.
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.
True, but what about the bootstrapping compiler, for new architectures? That can't be C. Neither can the libraries the compiler depends on. And you'll eventually have to rewrite the assembler, because that can't be C...
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.
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?
