471–480 of 511 posts
Earlier quoted context omitted.
That's the point, there are plenty of things that flat cannot be done without using inherently unsafe operations, even in rust. This is why it has still yet to be shown that rust is actually safer than C++.
That's not the point. Array types in Ruby and Python are implemented in C. No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).
Earlier quoted context omitted.
> I think the contention is that, unless you're applying NASA style rigor, you don't end up in the same place without verifying the safety automatically, because in practice it's too expensive to verify the safety manually (without getting squeezed out of the space by your competitors.) That's a claim that has yet to be shown to be true. Maybe it is true, and maybe it isn't, but C++ compilers tend to give pretty good…
> C++ compilers tend to give pretty good warnings that you can treat as errors They miss far too many simple cases for this to possibly be a sensible claim, e.g. neither gcc -Wall nor clang -Weverything warn about the two massive problems in the following code: #include int &foo() { std::vector v{ 0, 1, 2, 3 }; int &x = v[0]; v.clear(); int y = x; // dereferencing dangling pointer! (void)y; return x; // escaping a da…
Earlier quoted context omitted.
> C++ compilers tend to give pretty good warnings that you can treat as errors They miss far too many simple cases for this to possibly be a sensible claim, e.g. neither gcc -Wall nor clang -Weverything warn about the two massive problems in the following code: #include int &foo() { std::vector v{ 0, 1, 2, 3 }; int &x = v[0]; v.clear(); int y = x; // dereferencing dangling pointer! (void)y; return x; // escaping a da…
I'll have to check when I get home, but I'm fairly certain you're purposefully suppressing the compilers warnings here. That's not a good way to make your argument about the compiler not being able to warn you about problems.
Earlier quoted context omitted.
I'll have to check when I get home, but I'm fairly certain you're purposefully suppressing the compilers warnings here. That's not a good way to make your argument about the compiler not being able to warn you about problems.
Yes, I'm purposely suppressing the unused variable warning with the (void)y;, because presumably real code will actually do something with the value: I could've printed y or left out that line, whatever, the compilers still don't warn about the actual major problems.
I honestly don't think we should continue this conversation.
Earlier quoted context omitted.
Yes, I'm purposely suppressing the unused variable warning with the (void)y;, because presumably real code will actually do something with the value: I could've printed y or left out that line, whatever, the compilers still don't warn about the actual major problems.
Your argument as to why the compiler won't warn you about problems is to show an example where you purposefully supress the warnings the compiler gives you. I honestly don't think we should continue this conversation.
- unrelated to the dangling pointers
- not suppressing a warning about a memory safety problem
- not effecting the lack of warnings for the memory safety problems: remove the `(void)y;` line and there's still no warnings about the dangling pointers.
Seriously, you are focusing on something irrelevant. Either pretend I didn't write that line, or pretend it was std::cout not warn about the major problem of handling dangling pointers, despite both of these being fairly trivial cases, just a tiny step up from pure stack allocation.
Yes, C++ compilers do have some warnings for some things, but the interesting warnings for this topic are insidious memory safety bugs like dangling references, not the basic unused variable ones. Rust warns about both, C++ compilers catch only the second one: the code I wrote is wrong for two reasons, and neither of those reasons is the unused variable.
If you're going to tout the quality of C++ compiler's warnings, they better flag as many cases of problems like use after free (and use after move), dangling references and iterator invalidation as they can, but I've never had a C++ compiler warn about any of these (other than the most basic case of returning a reference to a local variable).
Earlier quoted context omitted.
As the author of ripgrep, I can assure you, the burden on me as the programmer was lifted quite a bit! I probably wouldn't have been able to build it otherwise. (Not because it's physically impossible, but because it would have taken too much time.) It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: htt…
Oh wow, The creator in the "flesh"! Thanks for replying to me. Hypothetical scenario: Let's say you're writing an experimental tool that doesn't exist anywhere else. You don't care about security, you don't care about speed. You just want it to exist so you can see what it does and possibly iterate on the idea if it ends up working out. Would Rust still be feasible? From my impression of it, you would need to take ca…
I will say that a comparison between Rust and C is much easier, because in the past, I've spent so much time debugging runtime errors in C with valgrind. Rust is an easy win there for me personally. I've never done much C++ so I can't provide a comparison point there.
After a bit of Rust coding you get quite familiar with the workings of the borrow checker, and it becomes pretty natural to work with it. There are plenty of things you can do in C that Rust's borrow checker will forbid because it isn't smart enough to prove it safe, but there are usually straight-forward work-arounds. Sometimes the borrow checker might even help make the code a bit clearer. :-) Some of this is institutional knowledge though, so there's still a lot more documentation work left to be done!
To bring this back to earth: Rust won't replace those ~100 line Python scripts that I sometimes write for quick data munging.
The other important bit of context is that before I started with Rust, I had already had quite a bit of experience with C, Standard ML and Haskell. This meant that the only truly new thing I had to cope with in Rust was the borrow checker, so it might have been easier for me to digest everything than it might have been for most.
Earlier quoted context omitted.
syntax
Be specific.
1) Drop the semicolons and implicit returns in multiline functions (I.e. like Swift). Eliminates hard to understand errors around missing or present semicolons.
2) Allow silent lossless integer upcasts. Sprinkling as usize and friends everywhere is unergonomic.
3) ? For return is fine but the line should still have one "try" at the beginning for legibility.
4) Allow full inference of generic type parameters. Would make it much easier to split code into helper functions.
5) Macros are nicer than in C but still hostile to comprehension.
There are others, but these are ones I've personally run into. Love the language and especially love Cargo but it has some newbie-hostile rough edges like this and others.
Earlier quoted context omitted.
Your argument as to why the compiler won't warn you about problems is to show an example where you purposefully supress the warnings the compiler gives you. I honestly don't think we should continue this conversation.
Suppressing the unused variable warning is: - unrelated to the dangling pointers - not suppressing a warning about a memory safety problem - not effecting the lack of warnings for the memory safety problems: remove the `(void)y;` line and there's still no warnings about the dangling pointers. Seriously, you are focusing on something irrelevant. Either pretend I didn't write that line, or pretend it was std::cout not…
I'm going to quote myself, emphasis mine.
"The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper."
[snip]
"C++ compilers tend to give pretty good warnings that you can treat as errors, and __coupled with good external tools__ it isn't clear that rust is significantly safer than C++."
Earlier quoted context omitted.
That's not the point. Array types in Ruby and Python are implemented in C. No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).
> No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?). It's unfortunate that you've chosen to try and make the scope smaller by referring specifically to "memory safety". As a result, this will be my last response to you, I just don't have the energy to go back and forth with someone who isn't willing to be honest in this discussion. But to answer your question, thos…
This definition makes any comparison of the safety of different languages totally useless: according to it, all languages are equally unsafe. You're free to want to use that definition, but it's a tautology and thus doesn't actually allow distinguishing between anything nor serve any purpose.
It's true that all languages offer escape hatches, but it's also true that there's a major qualitative (at least) difference between the constrained rarely used escape hatches of Python, Java and Rust, and the "the whole language is an escape hatch" approach of C++ and C.
In mathematics and the verification of programs, proofs will build from small proofs: first show that a function `foo` has a certain behaviour and then use this to show that `bar` (which calls `foo`) has another behaviour, etc etc, until the whole program is proved correct. Languages like Python, Java and Rust are designed with this in mind: prove the unsafe code correct and the language guarantees the rest of the code is memory safe. C and C++ have no such properly: a proof of memory safety requires touching every single line of code, not just the small number that actually need to escape down a level.
Earlier quoted context omitted.
That's not the point. Array types in Ruby and Python are implemented in C. No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?).
> No one goes around saying those languages are actually no more memory safe than C++ (or maybe you do?). It's unfortunate that you've chosen to try and make the scope smaller by referring specifically to "memory safety". As a result, this will be my last response to you, I just don't have the energy to go back and forth with someone who isn't willing to be honest in this discussion. But to answer your question, thos…