5 ms·
I was at the sidelines when Rust 1.0 was being made and I think it got into an llvm induced feedback loop. Slowly turning into C or C++ with other features but
by kzrdude 3y ago
I was at the sidelines when Rust 1.0 was being made and I think it got into an llvm induced feedback loop. Slowly turning into C or C++ with other features but the same type, object and memory model.
Part of the reason was Rust's desire to show itself as a direct competitor w.r.t performance, I think.
- Ygg2 3y agoPerformance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).
- intelVISA 3y agoThe fatal mistake here is using the STL...
- tialaramex 3y agoThe safe thing Rust did here is affordable in Rust (Option<T> is the same size as T for many T including all references) so they could afford to do it, whereas it's expensive in C++. Could it have been made cheaper in C++? Sure, but safety wasn't their priority so who cares? That prioritisation applies to the whole ISO language, not only to the standard library.
- pjmlp 3y agoTalking about C? https://godbolt.org/z/vYcMhE9h7 https://godbolt.org/z/vYcMhE9h7
- tialaramex 3y agoYou turned on a feature which helps diagnose this type of mistake at runtime, and it helped you by diagnosing the mistake at runtime. What does that prove? What I'm talking about is that Rust's Option is very cheap in all the cases where it can be very cheap, which makes this whole design feature more affordable. C++ eventually grew std::optional which is not powerful enough for this work and yet is also bigger and slower. They could have done better, but safety wasn't a priority.
- pjmlp 3y agoIt proves that there is a way to diagnose this type of mistake, that is what matters. Unlike C, which the only way to be safe is not to touch it at all. As for performance, ISO doesn't implement compilers, there are many ways to improve performance while keeping the semantics in line with the standard. If the compiler vendors decide to focus elsewhere is another matter, a bit like there are languages as complex as Rust and compile faster, because that has been a concern, whereas rustc developers have their concerns elsewhere.
- pjmlp 3y agoThe fatal mistake is not enabling bounds checking, which most STL implementations support.
- intelVISA 3y ago-Wabsolutely-everything I haven't written the Language of Kings in a while: does GCC -Wall truly enable all warnings yet?
- staunton 3y agoObviously not. It would be an instant scandal if they tried that.
- astrange 3y agoIt doesn't, and that would be a bad thing, because warnings aren't magic and bug-free themselves. Nor is there any reason to comply with every single warning every person in the world has come up with. clang has a -Weverything and it isn't supported.
- FpUser 3y agoAnd what should be defined behavior? There are quite a few choices that depend on particular situations. Feature designers have no knowledge about what would you want so they left it up to application programmer to check the situation upfront and act accordingly to their wishes. If you want same behavior across the whole application you can always write generic function doing just that.
- Ygg2 3y agoReturn either value or an EMPTY placeholder. Look Java did it. It returns a nullable value or Optional.
- FpUser 3y agoThen I have to check the result anyways. Same thing
- mughinn 3y agoYou should always check The argument is that Rust forces you and in C++ you can forget/the compiler can do what it wants
- Ygg2 3y agoNo. In Rust check is there by default, with optional unchecked access. In C++ the safety is off by default and you have to remember to check. It's like Yaml parsers, they had "load_yaml" which is unsafe and "safe_load_yaml" which is the secure option. Imagine no surprise when Rubyists went for shorter safe looking method and got their servers pwned.
- FpUser 3y agoI think you are wrong. I looked and in Rust doc it says that: "Removes the last element from a vector and returns it, or None if it is empty". You better be doing check for "None".
- 3y ago
- pjmlp 3y agoIn C++ it is an error, if one bothers to enable bounds checking. https://godbolt.org/z/vYcMhE9h7 https://godbolt.org/z/vYcMhE9h7 > Error: attempt to access an element in an empty container.
- dmm 3y agoSomeone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.
- pjmlp 3y agoYes, that is kind of true. It is also what attracted me into C++ coming from Turbo Pascal and Turbo Basic, back in the early 1990's. Although C++ culture could be much better towards safety, it is definitely better than whatever WG14 is doing, or C has brought into the picture for the last 50 years. Also anyone that just copy pastes C like code into C++, is the kind of developer that will be using unsafe{} all over the place, on the languages that have them.
- imtringued 3y agoTelling people to stop using unsafe is much easier than telling people to not have undefined behaviour. C developers like telling themselves that only people with bounded rationality make security critical mistakes. All the skilled C developers have ascended beyond the mortal realm and would never let themselves be chained up with crutches for the weak like affine types or overflow/bounds checking.
- worik 3y ago> a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day Yes you could. But I do not think " cultural" is the right term for not putting all your code in an `unsafe` block