3 ms·
I think you & GP are using different senses of replacement ("drop in replacement" vs. "replacement for greenfield projects"). You might consider Rust to be the
by maxbond 4y ago
I think you & GP are using different senses of replacement ("drop in replacement" vs. "replacement for greenfield projects"). You might consider Rust to be the latter (with qualifications, eg, excluding certain architectures & proprietary programming environments) but it's explicitly not the former (it's interoperable with C, but not compatible with C).
I think we should avoid saying "replacement" in general because eliminating all lines of C isn't a goal worth pursuing, C doesn't need to die for Rust to succeed, and there's room enough in this world for a hundred safe systems languages fulfilling different niches. I think a lot of people feel attacked & invalidated by the idea of a "C replacement" that isn't C compatible, like we're telling them their skills are no longer necessary or valuable, which is untrue & leads to flamewars and misunderstandings.
- zozbot234 4y agoRust is absolutely a "drop-in" replacement to C in most cases even for existing projects, it was absolutely built with that goal in mind. You can go as fine-grained as replacing a single function with a Rust-coded version (even using bindgen to ingest existing C headers) - though that generally involves unsafety because you're dealing with general pointers, extern calls and such. Even Checked C cannot prove these things 100% safe, it just catches common misuse. (Of course some C projects could abuse the preprocessor in ways that make it infeasible to even replace a C function with a Rust equivalent, but that's incredibly rare. And Rust has macro facilities of its own.)
- maxbond 4y agoWe're using different senses of "drop in", it's a bit of a vague term. Rust is interoperable with C (it can do C FFI) but it is not compatible with C (C code is not Rust code and Rust code is not C code). Compare this to a language like Carbon or C++; that is what I'd call a "drop in replacement", because they are compatible, using the definitions I've provided. If FFI were sufficient, Python would be a "C replacement." It's true that there is a path to integrating Rust into C projects and potentially replacing C in that project, I just see lots of threads on HN derailed by the statement "Rust is a C replacement", and I think using more nuanced language would help.
- zozbot234 4y agoBy that standard, Carbon is not compatible with C or C++, and neither is Cppfront. One could argue that C-style uses of pinned data or possibly-aliased pointers are not idiomatic in Rust and are a pitfall for interop with the Safe subset; nonetheless these uses can be expressed in the language.
- Tozen 4y agoAnd there are other languages that interop well with and have a FFI for C.
- xigoi 4y agoC++ is not source-compatible with C and never has been.