51–60 of 66 posts
Earlier quoted context omitted.
And how, might I ask, are you going to write your runtime for all these safe languages?
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
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++. Th…
> 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.
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
Won't work for any of the languages mentioned. Somewhere underneath it all you need a runtime witten in a bare metal language
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.
Earlier quoted context omitted.
> 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 t…
> 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…
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.
C (and, to a lesser extent, C++) absolutely will die. The way the languages are managed guarantees this. It's a myth that garbage collection is slow, and it's furthermore a myth that manual memory management is easy. So C (and, to a lesser extent, C++) will continue to lose ground for new projects to languages that take the requirement to manage memory off the programmer. Furthermore, while C and C++ require low-leve…
Aren't most systems written in C?
Earlier quoted context omitted.
> 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…
> 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…
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. I guess the fanboys will complain for me calling Rust unsafe. You can write "safer" programs in Rust just like you can in C++. Th…
And how, might I ask, are you going to write your runtime for all these safe languages?
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
Won't work for any of the languages mentioned. Somewhere underneath it all you need a runtime witten in a bare metal language
I don't care about Ruby or Python, both toy languages.
Earlier quoted context omitted.
And how, might I ask, are you going to write your runtime for all these safe languages?
Lisp compilers have been written in Lisp for the last 30 years or so...