I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.
I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. They are however not as fast as those using unsafe parts of the language. You will never get the same kind of total safety as you get in, say, Python because Rust doesn't do overflow checking. It does in debug mode, but you are strongly encouraged to distribute binaries in release mode since the speedup is substantial.
Offering safety and programming ergonomics for performance is a crappy trade.
Alternatively, Python could easily be argued as being radically unsafe compared to Rust, given the many, many libraries that call out to C and the ease of exploiting C libraries loaded by CPython.
Saying that wrap around doesn't lead to unsafety because "it is defined that way" is wrong. Wrap around is one of the leading causes of security issues in all software. Scroll down to the Quantifying the risk in the blog post. The author says that it is very hard not easy to exploit C libraries loaded by Python.
> A wrap around on its own can not cause unsafety in rust, only panics.
You are either misinformed or do not know what safety means. Integer types in Rust in release mode wraps around and that can lead to consequences much worse than crashing. Programs doing the exact opposite of what they were intended to.
Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety.
> Now I see that you are talking about MEMORY safety which I'm not. Writing safe programs includes so much more than just memory safety.
Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want.
> I have not seen a single CVE about the issue.
That's part of the point of the article. CVEs are rarely filed for memory safety issues in the underlying C libraries that make up the Python ecosystem.
> Yes, what rust claims is memory safety, not safety from all forms of bugs. If you don't want wrapping integers, you can compile with a flag to panic on overflow, or use types in std that will have the behavior you want.
Which was the point! High level languages have many more safety features than Rust have, such as non-wrapping integers. Trading those features for performance is foolish.
Claiming Rust or any other low-level language is on an "equal footing" with Python or any other high-level language because you have this and that feature is facetious. In C you can write your own types with bounds checking and even your own garbage collector to make your programs memory safe. Using dumb arguments like these we can claim C is as safe as Python. But the arguments are dumb because that is not how programs are written in the real world.
In the same way, claiming Rust is as safe as Python because it has a flag (that no one uses because it makes your programs twice as slow!) to perform wrap around checking and types in the standard library with correct behavior is dumb. It is what happens IN PRACTICE that matters.
Funny you should say that, because when you compile Rust programs in debug mode (e.g., how most tests are run), then overflow results in a panic. This isn't foolproof, but that's what "in practice" means. For me, overflow bugs tend to be caught in tests.
You're getting too hung up on one specific point (integer wrapping) and being too bombastic about it. Consider other facets of safety such as exception safety, data races and ownership.
> I really wish people would just forget about unsafe ("unsafe" as in Ruby is much safer) languages completely and embrace languages with safe run times. Rust, C, C++, Go and many more languages all need to "die" and be replaced with high-level languages; Lisp, Python, Ruby, Javascript, etc.
Someone needs to write the unsafe code so that the safe code can execute on top of it.
Indeed, however it is a big difference to write unsafe code in a code block that makes it explicitly to everyone, and having every line of code being a possible victim of 200+ UB possibilities, every string or array operation a possible memory corruption.
Not only it is possible, it has been done multiple times, the first OS written in a high level language was developed in 1961, about 8 years before any line of UNIX was written in Assembly.
And the first hypertext based software was developed at Xerox PARC, which also did not use any Bell Labs languages.
Rust, Go, Lisp do have certainly bootstraped compilers, with the runtime also written with them.
For Python and Ruby, it is a matter of someone actually taking the effort of doing it, which no one does because it would only be proving a point that anyone with major in compiler design already knows it is possible, just with lots of hard work.
I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. They are however not as fast as those using unsafe parts of the language. You will never get the same kind of total safety as you get in, say, Python because Rust doesn't do overflow checking. It does in debug mode, but you are strongly encouraged to distribute binaries in release mode since the speedup is substantial.
Offering safety and programming ergonomics for performance is a crappy trade.