4 ms·

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,

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.

staticassertion 8y ago
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. https://hackernoon.com/python-sandbox-escape-via-a-memory-corruption-bug-19dde4d5fea5?gi=f6ad2dd2d987 https://hackernoon.com/python-sandbox-escape-via-a-memory-co... I'd say more people have had to jump into "unsafe" Python than have had to jump into "unsafe" Rust. As for overflow checking, that won't lead to unsafety on its own, just panics (it's defined to wrap in release). Your post conflates all sorts of issues and lacks nuance.
- bjourne 8y ago
  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.
  - staticassertion 8y ago
    > Wrap around is one of the leading causes of security issues in all software. A wrap around on its own can not cause unsafety in rust, only panics. As in, maybe you try to use the wrapped integer as an array index, that's still safe even if it wraps (because Rust bounds checks). It would only case memory safety when used alongside code in an unsafe block. > The author says that it is very hard not easy to exploit C libraries loaded by Python. I drew a different conclusion from that section
    - bjourne 8y ago
      > 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. > I drew a different conclusion from that section I have not seen a single CVE about the issue.
      - staticassertion 8y ago
        > 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.
        bjourne 8y ago
        > 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.
saagarjha 8y ago
> 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.
- pjmlp 8y ago
  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.
Thorrez 8y ago
Is it possible to write an operating system or a browser if we forget about the languages you want us to forget about?
- pjmlp 8y ago
  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.
dmitrygr 8y ago
And how, might I ask, are you going to write your runtime for all these safe languages?
- bjourne 8y ago
  https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
  - dmitrygr 8y ago
    Won't work for any of the languages mentioned. Somewhere underneath it all you need a runtime witten in a bare metal language
    - pjmlp 8y ago
      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.
    - flavio81 8y ago
      Source of your claim? Lisp compilers have been written in Lisp for the last 30 years or so. I don't care about Ruby or Python, both toy languages.
- flavio81 8y ago
  Lisp compilers have been written in Lisp for the last 30 years or so...
  - lispm 8y ago
    The runtime for those implementations is usually written in a mix of (assembler and/or C) and Lisp.
cockboi 8y ago
Python, Lisp, Ruby and JavaScript are all slow as fuck languages. And you are completely wrong about Python being faster. Python is up to 100x slower than C++. How much crack did you smoke before writing this? Translation: I'm a webshit programmer who doesn't understand low level languages, and therefore they shouldn't be used
igouy 8y ago
https://www.inf.ethz.ch/personal/wirth/Oberon/index.html https://www.inf.ethz.ch/personal/wirth/Oberon/index.html

staticassertion 8y ago

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. https://hackernoon.com/python-sandbox-escape-via-a-memory-corruption-bug-19dde4d5fea5?gi=f6ad2dd2d987 https://hackernoon.com/python-sandbox-escape-via-a-memory-co... I'd say more people have had to jump into "unsafe" Python than have had to jump into "unsafe" Rust. As for overflow checking, that won't lead to unsafety on its own, just panics (it's defined to wrap in release). Your post conflates all sorts of issues and lacks nuance.

bjourne 8y ago
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.
- staticassertion 8y ago
  > Wrap around is one of the leading causes of security issues in all software. A wrap around on its own can not cause unsafety in rust, only panics. As in, maybe you try to use the wrapped integer as an array index, that's still safe even if it wraps (because Rust bounds checks). It would only case memory safety when used alongside code in an unsafe block. > The author says that it is very hard not easy to exploit C libraries loaded by Python. I drew a different conclusion from that section
  - bjourne 8y ago
    > 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. > I drew a different conclusion from that section I have not seen a single CVE about the issue.
    - staticassertion 8y ago
      > 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.
      - bjourne 8y ago
        > 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.

saagarjha 8y ago

> 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.

pjmlp 8y ago
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.

Thorrez 8y ago

Is it possible to write an operating system or a browser if we forget about the languages you want us to forget about?

pjmlp 8y ago
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.

dmitrygr 8y ago

And how, might I ask, are you going to write your runtime for all these safe languages?

bjourne 8y ago
https://en.wikipedia.org/wiki/Bootstrapping_(compilers) https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
- dmitrygr 8y ago
  Won't work for any of the languages mentioned. Somewhere underneath it all you need a runtime witten in a bare metal language
  - pjmlp 8y ago
    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.
  - flavio81 8y ago
    Source of your claim? Lisp compilers have been written in Lisp for the last 30 years or so. I don't care about Ruby or Python, both toy languages.
flavio81 8y ago
Lisp compilers have been written in Lisp for the last 30 years or so...
- lispm 8y ago
  The runtime for those implementations is usually written in a mix of (assembler and/or C) and Lisp.

cockboi 8y ago

Python, Lisp, Ruby and JavaScript are all slow as fuck languages. And you are completely wrong about Python being faster. Python is up to 100x slower than C++. How much crack did you smoke before writing this? Translation: I'm a webshit programmer who doesn't understand low level languages, and therefore they shouldn't be used

igouy 8y ago

https://www.inf.ethz.ch/personal/wirth/Oberon/index.html https://www.inf.ethz.ch/personal/wirth/Oberon/index.html