5 ms·

Exactly, show don't tell. And when I point to the fact that the Rust codebase itself has a lot of "unsafe" places I get the explanation "yes, but it's an old co

by acqq 10y ago

Exactly, show don't tell. And when I point to the fact that the Rust codebase itself has a lot of "unsafe" places I get the explanation "yes, but it's an old code and we haven't had the time to rewrite it to use the newer features that would allow more safe code." Think about it: the people who design Rust don't have the time to rewrite their own Rust code to be safe. When there's no time to rewrite the code of Rust to be demonstrably safe, why should any other project have more time than that, where the programmers know Rust much less or not at all? Maintaining the successful project is hard and takes a lot of time, even without switching to something new. Second point: look at the Benchmark game, a fast Rust code example also typically has an "unsafe" code. So it's still not even demonstrated that "you can have it both fast and safe" holds for these examples. Fast as in "as fast as C" and "safe" as in "provably safer than C." Finally, I believe that the language should simply implement a language-level no-cost check for integer overflow, as the machine languages already have, and not complain that there aren't some special mechanisms in CPUs to do it differently. It's your language's failure if you can't use what already exists. The CPUs already can do it, the high level languages don't provide the high-level access to it. Which doesn't matter for C which is "unsafe" by definition (and where it's natural to call some asm when needed) but it should for Rust which goal is to produce a more provably "safe" code. Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Also, look how Rust uses TLS. Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? I like the perspectives of what Rust could bring. But I'd like to see a real life case of its success too.

staticassertion 10y ago
> Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Your argument hinges pretty heavily on this. It's incorrect. The reality is that unsafe code in rust is not like unsafe code in C. First, it's bounded to a module. Second, you can grep for it (huge). Third, you still have less UB in unsafe rust than in C. I've never written code in rust that required unsafe, after many thousands of lines. > Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://github.com/ctz/rustls https://github.com/ctz/rustls ????????????? > But I'd like to see a real life case of its success too. Ripgrep is a nice one to point to. There's redox too. Tons of rust code out there.
- acqq 10y ago
  > It's incorrect. > I've never written code in rust that required unsafe, after many thousands of lines. That illustrates the level of understanding of those who argue that curl should be rewritten in rust. Bravo.
  - steveklabnik 10y ago
    Why, specifically?
    - acqq 10y ago
      It's self evident. One personal and very small example (many thousands is obviously less than 10 thousand) doesn't prove anything. curl has an order of 120000 non-empty lines in c and h files. The person who made statement of "many thousand" probably made toy applications, compared to something like curl. More realistic would be to compare something that should have been made in curl: like the "ring" library you mentioned as a Rust answer to "openssl." Which is neither an openssl nor written in Rust. It is far from providing the functionality of openssl. The author states that: "ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language." "ring is focused on general-purpose cryptography. WebPKI X.509 certificate validation is done in the webpki project, which is built on top of ring. Also, multiple groups are working on implementations of cryptographic protocols like TLS, SSH, and DNSSEC on top of ring." Actually a wrapper, and actually much smaller than openssl. Second, "ring" has just some 9000 lines in rs files but 13000 lines of C (as it is defined by the author to be a wrapper, not surprising). So it is still just a wrapper around the C, still orders of magnitude smaller than curl, and still unable to be actually written in Rust. On that level, I guess the Rust people would call curl the Rust application as soon as a few .rs files would appear in curl code base. Or not. It's simply has no sense, supporting Rust with misinformation instead of being honest about its current limitations regarding what's actually implemented and what actually doesn't use "unsafe." It's obvious that those who suggest to others to rewrite the big projects in Rust should first show that they managed to make some much smaller safe code. Especially that they managed to make some meaningful full-Rust and safe libraries.
steveklabnik 10y ago
> when I point to the fact that the Rust codebase itself has a lot of "unsafe" places One of the criteria for being in the standard library is "is this something which needs a lot of unsafe." This is so it can receive extra auditing, etc. > yes, but it's an old code This may have been true a while ago, but in my understanding (I'm not on the library team) it isn't really any more. > why should any other project have more time than that Because they do not need to write their own unsafe code, since it's already done in the standard library. Generally speaking, applications in Rust should almost never need unsafe. Libraries may. > a fast Rust code example also typically has an "unsafe" code. This is not really true anymore; in fact, recently some programs were contributed that are 100% safe yet are faster than their previous, unsafe-using versions. > believe that the language should simply implement a language-level no-cost check for integer overflow This is not viable. Not enough machines have this. > Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Unsafe Rust still has many, many more safety checks than C. > Also, look how Rust uses TLS. Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://crates.io/crates/ring https://crates.io/crates/ring ?
- acqq 10y ago
  > This is not viable. Not enough machines have this. Of course they have. It's a basic set of machine code instructions. Can you specify which doesn't please? > One of the criteria for being in the standard library is "is this something which needs a lot of unsafe." Do you honestly think a project like curl has everything it needs "which needs a lot of unsafe" already implemented in the current standard libraries? Why don't you rewrite the curl in Rust then, it's just using what's already written? Let me know how far you come. > https://crates.io/crates/ring https://crates.io/crates/ring ? Does it have all the features that curl needs, or does curl still have to use a Rust wrapper around openssl, inheriting all the potential unsafety problems of openssl anyway? What is worth then, in percentage, having anyway less exposed part of the code in Rust? How many other wrappers curl has to use? Have you tried to check and estimate if it's still worth? Once again, Rust people should first demonstrate that they can manage to make any relevant library "cleanly" safe, then complete the feature set, and only then expect big non-trivial programs consider using some Rust. First make the basics safe, then let us use that basics. Once you have save openssl equivalent, even C programs can link to it and be much less exposed to the potential problems than they are now. It's that direction that only has sense.
burntsushi 10y ago
> Second point: look at the Benchmark game, a fast Rust code example also typically has an "unsafe" code. That's false. From[1], it looks like two submissions use `unsafe`. And one of those is for ffi to gmp. [1] - http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html
- igouy 10y ago
  3 spectral-norm, 1 rev-comp http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=3 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... 2 pi-digits (ffi to gmp) http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
  - burntsushi 10y ago
    OK. I only looked at the programs linked directly from: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html
  - dbaupp 10y ago
    I think it's missing the point to count the programs that aren't the fastest, i.e. only one each of the spectral-norms and pi-digits are "interesting".
    - igouy 10y ago
      And apparently steveklabnik1 thinks it's missing the point to count other than "the latest version of each program". https://www.reddit.com/r/programming/comments/62cx5d/addendum_to_curl_is_c/dfm311a/ https://www.reddit.com/r/programming/comments/62cx5d/addendu... There are many ways to be selective with evidence. As-a-matter-of-fact all the contributed Rust programs I listed use unsafe.
igouy 10y ago
> Benchmark game, a fast Rust code example also typically has an "unsafe" code So you say but do not show. Please show us which of those Rust programs you count as "fast". Please show us how many of those programs have unsafe code.

by acqq 10y ago

staticassertion 10y ago

> Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Your argument hinges pretty heavily on this. It's incorrect. The reality is that unsafe code in rust is not like unsafe code in C. First, it's bounded to a module. Second, you can grep for it (huge). Third, you still have less UB in unsafe rust than in C. I've never written code in rust that required unsafe, after many thousands of lines. > Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://github.com/ctz/rustls https://github.com/ctz/rustls ????????????? > But I'd like to see a real life case of its success too. Ripgrep is a nice one to point to. There's redox too. Tons of rust code out there.

acqq 10y ago
> It's incorrect. > I've never written code in rust that required unsafe, after many thousands of lines. That illustrates the level of understanding of those who argue that curl should be rewritten in rust. Bravo.
- steveklabnik 10y ago
  Why, specifically?
  - acqq 10y ago
    It's self evident. One personal and very small example (many thousands is obviously less than 10 thousand) doesn't prove anything. curl has an order of 120000 non-empty lines in c and h files. The person who made statement of "many thousand" probably made toy applications, compared to something like curl. More realistic would be to compare something that should have been made in curl: like the "ring" library you mentioned as a Rust answer to "openssl." Which is neither an openssl nor written in Rust. It is far from providing the functionality of openssl. The author states that: "ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language." "ring is focused on general-purpose cryptography. WebPKI X.509 certificate validation is done in the webpki project, which is built on top of ring. Also, multiple groups are working on implementations of cryptographic protocols like TLS, SSH, and DNSSEC on top of ring." Actually a wrapper, and actually much smaller than openssl. Second, "ring" has just some 9000 lines in rs files but 13000 lines of C (as it is defined by the author to be a wrapper, not surprising). So it is still just a wrapper around the C, still orders of magnitude smaller than curl, and still unable to be actually written in Rust. On that level, I guess the Rust people would call curl the Rust application as soon as a few .rs files would appear in curl code base. Or not. It's simply has no sense, supporting Rust with misinformation instead of being honest about its current limitations regarding what's actually implemented and what actually doesn't use "unsafe." It's obvious that those who suggest to others to rewrite the big projects in Rust should first show that they managed to make some much smaller safe code. Especially that they managed to make some meaningful full-Rust and safe libraries.

steveklabnik 10y ago

> when I point to the fact that the Rust codebase itself has a lot of "unsafe" places One of the criteria for being in the standard library is "is this something which needs a lot of unsafe." This is so it can receive extra auditing, etc. > yes, but it's an old code This may have been true a while ago, but in my understanding (I'm not on the library team) it isn't really any more. > why should any other project have more time than that Because they do not need to write their own unsafe code, since it's already done in the standard library. Generally speaking, applications in Rust should almost never need unsafe. Libraries may. > a fast Rust code example also typically has an "unsafe" code. This is not really true anymore; in fact, recently some programs were contributed that are 100% safe yet are faster than their previous, unsafe-using versions. > believe that the language should simply implement a language-level no-cost check for integer overflow This is not viable. Not enough machines have this. > Writing unsafe Rust instead of unsafe C is not giving you any real advantage for the existing projects, as long as the state is as it is. Unsafe Rust still has many, many more safety checks than C. > Also, look how Rust uses TLS. Is safely rewriting a crypto library which is useful in real project still a too big task to be taken? https://crates.io/crates/ring https://crates.io/crates/ring ?

acqq 10y ago
> This is not viable. Not enough machines have this. Of course they have. It's a basic set of machine code instructions. Can you specify which doesn't please? > One of the criteria for being in the standard library is "is this something which needs a lot of unsafe." Do you honestly think a project like curl has everything it needs "which needs a lot of unsafe" already implemented in the current standard libraries? Why don't you rewrite the curl in Rust then, it's just using what's already written? Let me know how far you come. > https://crates.io/crates/ring https://crates.io/crates/ring ? Does it have all the features that curl needs, or does curl still have to use a Rust wrapper around openssl, inheriting all the potential unsafety problems of openssl anyway? What is worth then, in percentage, having anyway less exposed part of the code in Rust? How many other wrappers curl has to use? Have you tried to check and estimate if it's still worth? Once again, Rust people should first demonstrate that they can manage to make any relevant library "cleanly" safe, then complete the feature set, and only then expect big non-trivial programs consider using some Rust. First make the basics safe, then let us use that basics. Once you have save openssl equivalent, even C programs can link to it and be much less exposed to the potential problems than they are now. It's that direction that only has sense.

burntsushi 10y ago

> Second point: look at the Benchmark game, a fast Rust code example also typically has an "unsafe" code. That's false. From[1], it looks like two submissions use `unsafe`. And one of those is for ffi to gmp. [1] - http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html

igouy 10y ago
3 spectral-norm, 1 rev-comp http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=3 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=revcomp&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... 2 pi-digits (ffi to gmp) http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=rust&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=rust&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
- burntsushi 10y ago
  OK. I only looked at the programs linked directly from: http://benchmarksgame.alioth.debian.org/u64q/rust.html http://benchmarksgame.alioth.debian.org/u64q/rust.html
- dbaupp 10y ago
  I think it's missing the point to count the programs that aren't the fastest, i.e. only one each of the spectral-norms and pi-digits are "interesting".
  - igouy 10y ago
    And apparently steveklabnik1 thinks it's missing the point to count other than "the latest version of each program". https://www.reddit.com/r/programming/comments/62cx5d/addendum_to_curl_is_c/dfm311a/ https://www.reddit.com/r/programming/comments/62cx5d/addendu... There are many ways to be selective with evidence. As-a-matter-of-fact all the contributed Rust programs I listed use unsafe.

igouy 10y ago

> Benchmark game, a fast Rust code example also typically has an "unsafe" code So you say but do not show. Please show us which of those Rust programs you count as "fast". Please show us how many of those programs have unsafe code.