8 ms·

Pretty sure from a build system perspective its quite a flex .. to be fair.

eesmith 3y ago
I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself (eg, the FORTRAN code in Sibson's 1973 "SLINK" paper), or only distributed as a zip file from the author's web site, or in the supplementary data (eg, https://scholar.google.com/scholar?q=%22source+code+in+the+supplementary%22 https://scholar.google.com/scholar?q=%22source+code+in+the+s... ) . Personally, I don't think it's true. I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.
- dralley 3y ago
  >if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. You seem to be suggesting that it's a good thing that the public code is spread across so many different places that it cannot all be found. I don't see how that's an inherently good thing. It says less about the total amount of code than it does about the lack of any central resource that can be consulted.
  - eesmith 3y ago
    > that it cannot all be found. Do you think you can find all public Rust code? Like, if I'm teaching a Rust course, and put a hello-world.rs program on my department's public GitLab instance, under an MIT license, do you think I should also put that on GitHub? And register it as a crate? > the lack of any central resource that can be consulted. And you say that like it's a good thing. You want everything to be centralized on GitHub? If so, you want to force all research software developers to agree to the GitHub's terms, including those who are ardent free software advocates. You also prevent 12 years olds from publishing their Rust source code. (GitHub's terms of service don't allow that.) Or, do you also allow BitBucket [1], and GitLab [2]? [1] https://bitbucket.org/project_samar/samar_lite/src/master/ https://bitbucket.org/project_samar/samar_lite/src/master/ contains two Rust programs, neither on crates.io [2] https://gitlab.com/rouault-team-public/analysis/umaprs https://gitlab.com/rouault-team-public/analysis/umaprs What about department instances of GitLab? [3] https://gitlab.anu.edu.au/mu/mu-impl-fast/-/tree/rtmu-dev https://gitlab.anu.edu.au/mu/mu-impl-fast/-/tree/rtmu-dev It really doesn't seem like it's all that easy to find all publicly available Rust code.
    - dralley 3y ago
      What bearing does any of this have on the previous thread of discussion? Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? The purpose of Crater is uncovering subtle compiler regressions. If "hello world" is ever broken then it would likely be discovered by the standard test suite or generally long before the Crater run. This isn't a matter of "allowing" anything. It's just a statement that yes a Crater run does test all meaningful publicly available code, where "meaningful" at the very least means code which is consumed via crates.io. Sure, there is very likely public code that exists elsewhere which Crater cannot find, and that's OK. The point is that a Crater run coming back clean means something, because a very very wide swath of code was tested.
      - eesmith 3y ago
        What is "the previous thread of discussion?" My response was all of 5 lines, saying that if dthul's comment were true, then it implies that Rust has a rather small code base. And indeed, Crater does not test all publicly available Rust code. ("Not all code is on crates.io! There is a lot of code in repos on GitHub and elsewhere", and only for "Linux builds on x86_64", not Windows, says https://rustc-dev-guide.rust-lang.org/tests/crater.html https://rustc-dev-guide.rust-lang.org/tests/crater.html). Rust is much bigger than dthul's comment implies. You may well be correct when adding the qualifier "meaningful", but that's a different thread of discussion. > Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? I mentioned that because you changed the thread of discussion to discuss centralized vs. decentralized code distribution. > because a very very wide swath of code was tested. And C++ language developers also analyze a 'wide swath of code' - millions of lines or more - for changes.
  - 59nadir 3y ago
    To be fair to the original argument, I think it's important to understand that there is next to no Rust code in comparison to the amount of C++ code out there. It has almost no projects in comparison, and those projects are much, much smaller. I don't think that's a very controversial statement, because it's very obviously true. Now, it's also important to keep in mind that C++ has a terrible story when it comes to centralized (or otherwise, really?) repositories for packages, so the corresponding system for C++ is at the moment completely infeasible and not at all useful. That doesn't really make the Rust code that's tested against any more meaningful in comparison to the vast amounts of C++ code out there, though. Edit: At the kind of pointless and debilitating scale that C++ exists and then with the relationship C++ has with packages and dependency management this entire idea is basically impossible.
- tialaramex 3y ago
  Rather than hypothesising about an imagined tool you could look at the actual tool which of course is in Rust's source code repo: https://github.com/rust-lang/crater https://github.com/rust-lang/crater > new proposed C++ changes - are checked against only easily and "well-known" accessible package. Now that I have, so to say, shown you mine, lets see yours. Where is the tool to perform these checks in C++?
  - eesmith 3y ago
    Thank you for showing that I was right to in my belief: 'I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.' My point is that dthul's comment "they usually test it against all publicly available Rust code" implies Rust has a very small user base. Since crater runs only against "parts of the Rust" - those available on GitHub and crates - it implies a rather larger ecosystem. As for "mine" - what I know about C++ development comes from reading links posted to HN; hardly "mine" in any meaningful sense. I also don't accept your wording "these checks", because my point is that similarly useful checks are done, not exactly identical tests. I wrote 'FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.' From previous readings, I know they do code surveys, and experiments using existing code bases and compilers. For examples, there's https://codesearch.isocpp.org/ https://codesearch.isocpp.org/ ("developed for ISO Standard C++ proposal authors in order to explore existing C++ practice and to provide empirical evidence to support claims about existing practice made in proposals.") done in surveys to understand how code is used. For example, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14... . At https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1161r3#without-duplication-caused-by-headers-included-multiple-times-throughout-a-project https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p11... they used a custom tool to analyze Boost, Chromium, Firefox, the Linux Kernel, Libreoffice, LLVM, and Qt: "Estimated 30 to 80 millions LOC compiled".
    - tialaramex 3y ago
      I don't see "We sometimes do some ad hoc checks including looking for stuff with code search" as "similarly useful" to using proper test automation at all. And I think the results continue to speak for themselves.

I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself (eg, the FORTRAN code in Sibson's 1973 "SLINK" paper), or only distributed as a zip file from the author's web site, or in the supplementary data (eg, https://scholar.google.com/scholar?q=%22source+code+in+the+supplementary%22 https://scholar.google.com/scholar?q=%22source+code+in+the+s... ) . Personally, I don't think it's true. I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.

dralley 3y ago
>if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. You seem to be suggesting that it's a good thing that the public code is spread across so many different places that it cannot all be found. I don't see how that's an inherently good thing. It says less about the total amount of code than it does about the lack of any central resource that can be consulted.
- eesmith 3y ago
  > that it cannot all be found. Do you think you can find all public Rust code? Like, if I'm teaching a Rust course, and put a hello-world.rs program on my department's public GitLab instance, under an MIT license, do you think I should also put that on GitHub? And register it as a crate? > the lack of any central resource that can be consulted. And you say that like it's a good thing. You want everything to be centralized on GitHub? If so, you want to force all research software developers to agree to the GitHub's terms, including those who are ardent free software advocates. You also prevent 12 years olds from publishing their Rust source code. (GitHub's terms of service don't allow that.) Or, do you also allow BitBucket [1], and GitLab [2]? [1] https://bitbucket.org/project_samar/samar_lite/src/master/ https://bitbucket.org/project_samar/samar_lite/src/master/ contains two Rust programs, neither on crates.io [2] https://gitlab.com/rouault-team-public/analysis/umaprs https://gitlab.com/rouault-team-public/analysis/umaprs What about department instances of GitLab? [3] https://gitlab.anu.edu.au/mu/mu-impl-fast/-/tree/rtmu-dev https://gitlab.anu.edu.au/mu/mu-impl-fast/-/tree/rtmu-dev It really doesn't seem like it's all that easy to find all publicly available Rust code.
  - dralley 3y ago
    What bearing does any of this have on the previous thread of discussion? Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? The purpose of Crater is uncovering subtle compiler regressions. If "hello world" is ever broken then it would likely be discovered by the standard test suite or generally long before the Crater run. This isn't a matter of "allowing" anything. It's just a statement that yes a Crater run does test all meaningful publicly available code, where "meaningful" at the very least means code which is consumed via crates.io. Sure, there is very likely public code that exists elsewhere which Crater cannot find, and that's OK. The point is that a Crater run coming back clean means something, because a very very wide swath of code was tested.
    - eesmith 3y ago
      What is "the previous thread of discussion?" My response was all of 5 lines, saying that if dthul's comment were true, then it implies that Rust has a rather small code base. And indeed, Crater does not test all publicly available Rust code. ("Not all code is on crates.io! There is a lot of code in repos on GitHub and elsewhere", and only for "Linux builds on x86_64", not Windows, says https://rustc-dev-guide.rust-lang.org/tests/crater.html https://rustc-dev-guide.rust-lang.org/tests/crater.html). Rust is much bigger than dthul's comment implies. You may well be correct when adding the qualifier "meaningful", but that's a different thread of discussion. > Why do you think a 12 year old needs to publish their "hello world" programs because of Crater? I mentioned that because you changed the thread of discussion to discuss centralized vs. decentralized code distribution. > because a very very wide swath of code was tested. And C++ language developers also analyze a 'wide swath of code' - millions of lines or more - for changes.
- 59nadir 3y ago
  To be fair to the original argument, I think it's important to understand that there is next to no Rust code in comparison to the amount of C++ code out there. It has almost no projects in comparison, and those projects are much, much smaller. I don't think that's a very controversial statement, because it's very obviously true. Now, it's also important to keep in mind that C++ has a terrible story when it comes to centralized (or otherwise, really?) repositories for packages, so the corresponding system for C++ is at the moment completely infeasible and not at all useful. That doesn't really make the Rust code that's tested against any more meaningful in comparison to the vast amounts of C++ code out there, though. Edit: At the kind of pointless and debilitating scale that C++ exists and then with the relationship C++ has with packages and dependency management this entire idea is basically impossible.
tialaramex 3y ago
Rather than hypothesising about an imagined tool you could look at the actual tool which of course is in Rust's source code repo: https://github.com/rust-lang/crater https://github.com/rust-lang/crater > new proposed C++ changes - are checked against only easily and "well-known" accessible package. Now that I have, so to say, shown you mine, lets see yours. Where is the tool to perform these checks in C++?
- eesmith 3y ago
  Thank you for showing that I was right to in my belief: 'I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.' My point is that dthul's comment "they usually test it against all publicly available Rust code" implies Rust has a very small user base. Since crater runs only against "parts of the Rust" - those available on GitHub and crates - it implies a rather larger ecosystem. As for "mine" - what I know about C++ development comes from reading links posted to HN; hardly "mine" in any meaningful sense. I also don't accept your wording "these checks", because my point is that similarly useful checks are done, not exactly identical tests. I wrote 'FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.' From previous readings, I know they do code surveys, and experiments using existing code bases and compilers. For examples, there's https://codesearch.isocpp.org/ https://codesearch.isocpp.org/ ("developed for ISO Standard C++ proposal authors in order to explore existing C++ practice and to provide empirical evidence to support claims about existing practice made in proposals.") done in surveys to understand how code is used. For example, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14... . At https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1161r3#without-duplication-caused-by-headers-included-multiple-times-throughout-a-project https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p11... they used a custom tool to analyze Boost, Chromium, Firefox, the Linux Kernel, Libreoffice, LLVM, and Qt: "Estimated 30 to 80 millions LOC compiled".
  - tialaramex 3y ago
    I don't see "We sometimes do some ad hoc checks including looking for stuff with code search" as "similarly useful" to using proper test automation at all. And I think the results continue to speak for themselves.