4 ms·

> Implementations are irrelevant And that's why Rust started from scratch. I totally understand the problem and the justification to address it. Yet nobody has

> Implementations are irrelevant And that's why Rust started from scratch. I totally understand the problem and the justification to address it. Yet nobody has ever been able to justify why it's necessary to dispense with the entirety of C and C++ to achieve memory safety. The power of frameworks like LLVM give you freedom to implement whatever semantics you want. Rust wouldn't have gotten off the ground if it weren't for that kind of power. I feel this power has been abused. For example, you could create a fork of C++ that merely compile-errors when you use a pointer and not a reference unless you enclose it in some `unsafe` block that you invented -- anything you want like that is possible. One can simply start with C++ augmented so that everything is const by default; that is the ideal progress to me. There's still no justification for Rust to be completely hausdorff to the last 50 years of established C systems and start over. If Rust doesn't really offer anything substantive for this amount of divergence I feel it will always be relegated to wrappers and a niche community. That just makes Rust a simulacrum.

maximilianburke 7y ago
> For example, you could create a fork of C++ that merely compile-errors when you use a pointer and not a reference unless you enclose it in some `unsafe` block that you invented -- anything you want like that is possible. One can simply start with C++ augmented so that everything is const by default; that is the ideal progress to me. But then it wouldn't be C++, it would be something else. You would very quickly end up with a language incompatible with C or C++ if you set off to implement the safety mechanisms of Rust on top of them. I mean, look at how long it took to get modules into C++, and that's a feature that is opt-in and won't change the semantics of existing code. You can't "simply start with C++" for anything. > There's still no justification for Rust to be completely hausdorff to the last 50 years of established C systems and start over. C and C++ aren't static either. They're evolving too and modern iterations of the language aren't compatible, or even recognizable, from the earlier incantations. (Is the big hangup here that Rust puts the type on the right side of the variable name?) > If Rust doesn't really offer anything substantive for this amount of divergence I feel it will always be relegated to wrappers and a niche community. If you're coming from a background of C++ development it's not that hard to pick up Rust. The borrow checker can be a bit of a pain but it isn't mysterious; it's got a well defined set of rules it plays with. There's a lot more to Rust than memory safety, it has a well laid out feature set that is refreshing and probably not implementable in C++ in my lifetime. The trait-based generics are great, the metaprogramming facilities are great, pattern matching is killer, that (nearly) everything is an expression is something C and C++ desperately need, and the out-of-the-box tooling is phenomenal. I get that Rust isn't for everyone, but painting it as irrelevant and unnecessary is too extreme, and arguably wrong if it's inspiring linting tools that bring some of Rust's rules to the C/C++ world, or inspiring language features. On a side note, what do you think of Apple moving away from Objective C toward Swift?
- jasonzemos 7y ago
  So my running conclusion is that Rust's founding decisions were made with a sort of "go big or go home" logic given this premise. To conclude that breaking even one part of C/C++ is grounds to throw up one's hands and drain the baby with the bathwater makes sense through this prism. At that point one might as well pour through the literature and academic languages to pick out all the goodies and gimmicks that haven't been mainstreamed before too. The problem here is that Rust is not graceful replacement for C/C++. I'm being sold on Rust from a systems perspective and the system is already written in C. It's a simple and incomplete language begging for extension but it's done a good job of abstractly representing commodity computing hardware to a programmer for 50 years. Rust doesn't even make an attempt to gracefully regrade C/C++ into Safe-C++ and I can't come to any other conclusion that this is for nothing more than a lack of creativity. There is an ignorance to the real costs of reinventing the wheel when one doesn't replace the original wheel too. That's why I am starting to truly convince myself Rust is actually harmful. If Rust gracefully took C in another direction (like C++ did), I could add Rust compilation units to my projects and share C interfaces which basically give me access to the entire existing universe so long as I use something like `extern "Rust" {` or visa-versa. If Rust broke ~10% of C++ I could put forth ~10% effort to port my projects to it and integrate it entirely. At a certain point down that vector, Rust can be the messianic "C++ done right" without looking back.
steveklabnik 7y ago
> Yet nobody has ever been able to justify why it's necessary to dispense with the entirety of C and C++ to achieve memory safety. As soon as you make a backwards incompatible change, you've already made a new language, effectively. Because: > For example, you could create a fork of C++ that merely compile-errors when you use a pointer and not a reference unless you enclose it in some `unsafe` block that you invented This means that effectively all C++ code would fail to compile under this implementation. > One can simply start with C++ augmented so that everything is const by default; that is the ideal progress to me. This is nowhere near enough to achieve the goal. Sure, it's a thing someone could do. But it's kind of irrelevant.
- jasonzemos 7y ago
  > This means that effectively all C++ code would fail to compile under this implementation. You're implying that all C++ code uses pointers and that's patently false. It's even false for C code. Pointers was the first thing C++ boxed with references. Box it more. Forks of C++ even exist, like GNU++ extensions. There's a whole spectrum of possibilities between that and where you are right now and I don't see why everyone needs to cross this chasm and embrace Rust at this cost. Breaking one part of the language doesn't break everything for everyone. That's definitely a fallacy if it couches the justification I'm chasing here.

maximilianburke 7y ago

> For example, you could create a fork of C++ that merely compile-errors when you use a pointer and not a reference unless you enclose it in some `unsafe` block that you invented -- anything you want like that is possible. One can simply start with C++ augmented so that everything is const by default; that is the ideal progress to me. But then it wouldn't be C++, it would be something else. You would very quickly end up with a language incompatible with C or C++ if you set off to implement the safety mechanisms of Rust on top of them. I mean, look at how long it took to get modules into C++, and that's a feature that is opt-in and won't change the semantics of existing code. You can't "simply start with C++" for anything. > There's still no justification for Rust to be completely hausdorff to the last 50 years of established C systems and start over. C and C++ aren't static either. They're evolving too and modern iterations of the language aren't compatible, or even recognizable, from the earlier incantations. (Is the big hangup here that Rust puts the type on the right side of the variable name?) > If Rust doesn't really offer anything substantive for this amount of divergence I feel it will always be relegated to wrappers and a niche community. If you're coming from a background of C++ development it's not that hard to pick up Rust. The borrow checker can be a bit of a pain but it isn't mysterious; it's got a well defined set of rules it plays with. There's a lot more to Rust than memory safety, it has a well laid out feature set that is refreshing and probably not implementable in C++ in my lifetime. The trait-based generics are great, the metaprogramming facilities are great, pattern matching is killer, that (nearly) everything is an expression is something C and C++ desperately need, and the out-of-the-box tooling is phenomenal. I get that Rust isn't for everyone, but painting it as irrelevant and unnecessary is too extreme, and arguably wrong if it's inspiring linting tools that bring some of Rust's rules to the C/C++ world, or inspiring language features. On a side note, what do you think of Apple moving away from Objective C toward Swift?

jasonzemos 7y ago
So my running conclusion is that Rust's founding decisions were made with a sort of "go big or go home" logic given this premise. To conclude that breaking even one part of C/C++ is grounds to throw up one's hands and drain the baby with the bathwater makes sense through this prism. At that point one might as well pour through the literature and academic languages to pick out all the goodies and gimmicks that haven't been mainstreamed before too. The problem here is that Rust is not graceful replacement for C/C++. I'm being sold on Rust from a systems perspective and the system is already written in C. It's a simple and incomplete language begging for extension but it's done a good job of abstractly representing commodity computing hardware to a programmer for 50 years. Rust doesn't even make an attempt to gracefully regrade C/C++ into Safe-C++ and I can't come to any other conclusion that this is for nothing more than a lack of creativity. There is an ignorance to the real costs of reinventing the wheel when one doesn't replace the original wheel too. That's why I am starting to truly convince myself Rust is actually harmful. If Rust gracefully took C in another direction (like C++ did), I could add Rust compilation units to my projects and share C interfaces which basically give me access to the entire existing universe so long as I use something like `extern "Rust" {` or visa-versa. If Rust broke ~10% of C++ I could put forth ~10% effort to port my projects to it and integrate it entirely. At a certain point down that vector, Rust can be the messianic "C++ done right" without looking back.

steveklabnik 7y ago

> Yet nobody has ever been able to justify why it's necessary to dispense with the entirety of C and C++ to achieve memory safety. As soon as you make a backwards incompatible change, you've already made a new language, effectively. Because: > For example, you could create a fork of C++ that merely compile-errors when you use a pointer and not a reference unless you enclose it in some `unsafe` block that you invented This means that effectively all C++ code would fail to compile under this implementation. > One can simply start with C++ augmented so that everything is const by default; that is the ideal progress to me. This is nowhere near enough to achieve the goal. Sure, it's a thing someone could do. But it's kind of irrelevant.

jasonzemos 7y ago
> This means that effectively all C++ code would fail to compile under this implementation. You're implying that all C++ code uses pointers and that's patently false. It's even false for C code. Pointers was the first thing C++ boxed with references. Box it more. Forks of C++ even exist, like GNU++ extensions. There's a whole spectrum of possibilities between that and where you are right now and I don't see why everyone needs to cross this chasm and embrace Rust at this cost. Breaking one part of the language doesn't break everything for everyone. That's definitely a fallacy if it couches the justification I'm chasing here.