3 ms·

This release got delayed a bit but I think it was for great reasons and really showcases the straights of the Julia community and core developer team. My under

This release got delayed a bit but I think it was for great reasons and really showcases the straights of the Julia community and core developer team. My understanding (please correct my if I’m wrong somewhere) is that in Julia, for releases which are supposed to be non-breaking such as 1.2, the Julia devs run the test suites of every registered Julia package on stables versions and then on their release candidate and then go through any regressions and identifies any unforeseen breakages that occurred and then either fix them in the Julia release candidate or if the package relies on an internal implementation detail which is not guaranteed to be stable, they will often try to help the package owners fix the regression. That’s seriously impressive and while I’m sure it happens in other languages, I hadn’t heard of a programme like that and thought it was worth mentioning here as the happy reason why this release was delayed.

fluffything 7y ago
This process is common for modern languages with modern tooling and that's a good thing. The Rust project has a tool called `crater` that can build all crates in crates.io and run their tests, a process that takes a couple of days. It also has a github bot that allows running crater on PRs on demand. This is super super useful and something that all programming languages should have. It allows you to: * make sure that a new Rust release doesn't break code that compiled with old releases. * assess the impact of a PR implementing a breaking change (e.g. due to a bug fix) * obtain quantitative data about language usage for language evolution. This last point is probably the most impactful. When I was working on C++, a question like "How much people are doing X?" would often come up. What did we do? Stakeholders in C++ meetings would travel back home, grep their codebases for the X pattern, and report back 6 months later. And that's it. That's all evidence we were hoping to get. And this was often super biased due to different coding guidelines and styles in the different companies. In Rust, you open a PR that makes doing X trigger a compilation error, schedule a crater run, and get a list of all places in all crates in crates.io where the error is triggered. This gives you quantitative information about how often is X done in the wild, and you can then go and analyze the code doing X and obtain even more information. It's hard to convey how important this is. You'll never have to read discussions about "I've never seen X in the wild" vs "I see X in the wild all the time". Those discussions make no sense when you have a tool that can actually tell you the answer. Every programming language being evolved today should have something like this.
- tsbinz 7y ago
  Don't you run into sampling bias this way since not everything is published on crates.io? (I'm not saying that having that tool is a bad thing, just saying that maybe that tool doesn't give you the actual answer ...)
  - dtech 7y ago
    There's no better data set, and it's not a big assumption to assume closed source/unpublished code has roughly the same usage patterns.
- dtech 7y ago
  Partially the same for Scala. They build the (currently) 185 most used open source projects. Very important since they just did a major overhaul of the stdlib and are working on a major overhaul of the compiler (Scala 3.x/Dotty)
Bootvis 7y ago
For R and CRAN this is also being done. Maybe not with 100% coverage (there are 14k packages on CRAN) but an attempt is made to fix packages by R-core developers if breakage occurs.
draegtun 7y ago
Perl/CPAN has been doing this for years - http://cpantesters.org/page/about.html http://cpantesters.org/page/about.html Here's an example of a CPAN module (Moose) which is tested against every release of Perl (going back to 5.8.3 from 2004) against multiple OS/Platforms - http://matrix.cpantesters.org/?dist=Moose http://matrix.cpantesters.org/?dist=Moose

fluffything 7y ago

This process is common for modern languages with modern tooling and that's a good thing. The Rust project has a tool called `crater` that can build all crates in crates.io and run their tests, a process that takes a couple of days. It also has a github bot that allows running crater on PRs on demand. This is super super useful and something that all programming languages should have. It allows you to: * make sure that a new Rust release doesn't break code that compiled with old releases. * assess the impact of a PR implementing a breaking change (e.g. due to a bug fix) * obtain quantitative data about language usage for language evolution. This last point is probably the most impactful. When I was working on C++, a question like "How much people are doing X?" would often come up. What did we do? Stakeholders in C++ meetings would travel back home, grep their codebases for the X pattern, and report back 6 months later. And that's it. That's all evidence we were hoping to get. And this was often super biased due to different coding guidelines and styles in the different companies. In Rust, you open a PR that makes doing X trigger a compilation error, schedule a crater run, and get a list of all places in all crates in crates.io where the error is triggered. This gives you quantitative information about how often is X done in the wild, and you can then go and analyze the code doing X and obtain even more information. It's hard to convey how important this is. You'll never have to read discussions about "I've never seen X in the wild" vs "I see X in the wild all the time". Those discussions make no sense when you have a tool that can actually tell you the answer. Every programming language being evolved today should have something like this.

tsbinz 7y ago
Don't you run into sampling bias this way since not everything is published on crates.io? (I'm not saying that having that tool is a bad thing, just saying that maybe that tool doesn't give you the actual answer ...)
- dtech 7y ago
  There's no better data set, and it's not a big assumption to assume closed source/unpublished code has roughly the same usage patterns.
dtech 7y ago
Partially the same for Scala. They build the (currently) 185 most used open source projects. Very important since they just did a major overhaul of the stdlib and are working on a major overhaul of the compiler (Scala 3.x/Dotty)

Bootvis 7y ago

For R and CRAN this is also being done. Maybe not with 100% coverage (there are 14k packages on CRAN) but an attempt is made to fix packages by R-core developers if breakage occurs.

draegtun 7y ago

Perl/CPAN has been doing this for years - http://cpantesters.org/page/about.html http://cpantesters.org/page/about.html Here's an example of a CPAN module (Moose) which is tested against every release of Perl (going back to 5.8.3 from 2004) against multiple OS/Platforms - http://matrix.cpantesters.org/?dist=Moose http://matrix.cpantesters.org/?dist=Moose