> IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in

> IMO it’s a ridiculous comment until large C/C++ projects (e.g. Linux, LLVM, Postgres/SQLite, big AI/ML toolkits) are mostly rewritten in Rust or overtaken in market share by alternatives written in Rust. Given this super high bar, I'm not sure any language would fit the mold of "legacy". I could just as easily say COBOL isn't legacy given this standard, as the world has not chosen to rewrite most of its COBOL software in Java yet, although we tend to think of COBOL as the legacy language. So I disagree with your definition of "legacy". "Not considered for greenfield development" seems like a better definition of legacy to me. So, yes, the term "legacy" for C/C++ would seem a little heavy handed for all software domains. But, for the software domain `fish` is targeting, it's not a ridiculous claim. Lots of the new, interesting stuff happening in systems-y, tools-y CLI stuff is happening in Rust. That isn't to say all of it is, or C/C++ isn't used ever, but if the OP said, "Look at the trajectory", and "Can you imagine writing a new shell in C or C++ in 10 years?", I might have to agree. Or, more concretely, if the OP said, "I personally can't imagine writing my open source software CLI tool in C or C++ in 10 years", I would definitely agree.