3 ms·

The same issues exist for other languages and runtimes so I'm not sure why Rust having a standard solution is a disincentive. How many ways are there to ruin a

The same issues exist for other languages and runtimes so I'm not sure why Rust having a standard solution is a disincentive. How many ways are there to ruin a python environment?

avhon1 6y ago
The issue is worse with Rust, which is still a young and rapidly-changing language. Debian stable currently packages rustc 1.41.1 (February 2020), which is 11 releases behind the most recent 1.48.0 release. The older compiler's differences after 10 months include: * doesn't have subslice patterns * has `Error::description`, which has since been deprecated * doesn't have x86 CPU feature detection * lacks fix for unsound typecasts between integers and floats * lacks fix for incomplete constant propagation * doesn't let you use conditionals, loops, match, $$, or || in constant fns, or cast arrays to slices in constant fns * has less-helpful error messages and backtraces * doesn't let you implement traits on arrays with lengths >32 * has worse type inference, this (valid since 1.43.0) code doesn't compile because 0.0 and &0.0 are f64s: let n: f32 = 0.0 + &0.0; * requires you to import standard libraries to use predefined numeric constants (like MAXINT or NaN) * doesn't support Control Flow Guard on Windows * doesn't generate documentation links from classpaths (you have to write relative file paths instead) and numerous libraries being pre-stable. For code that you're writing yourself, not having these features is mostly just a quality-of-life issue: you'll have to do things that you wouldn't have to do if you had the latest compiler. For code that you're collaborating on, having an 10-months-older compiler can be a showstopper: the code might just not compile at all, and very likely the only fix will be to uninstall your system-packaged rustc and install the version from rustup. Contrast this with C/C++ development, where your system's pre-packaged compilers are much more likely to be sufficiently up-to-date. These languages are more mature than Rust: they change slower, and new features are adopted by programmers more gradually. For example, the Linux kernel only requires GCC 4.9 [1], which was released in 2013. Debian stable supplies GCC 8.3, which will probably be able to compile unmodified kernel source code for many years without being updated. [1] https://www.kernel.org/doc/html/latest/process/changes.html https://www.kernel.org/doc/html/latest/process/changes.html
- lock-free 6y ago
  I can contrast with C/C++ development, where C++17/20 are not available by default on many distros because package managers lag so far behind the curve and new projects get tied to outdated versions. I just don't really see this as a problem - Rust really isn't that much of a moving target, and the benefit is there is one solution to the problem: use Rustup to manage your Rust installation. That is significantly more robust than "use your package manager."

The same issues exist for other languages and runtimes so I'm not sure why Rust having a standard solution is a disincentive. How many ways are there to ruin a python environment?

avhon1 6y ago

The issue is worse with Rust, which is still a young and rapidly-changing language. Debian stable currently packages rustc 1.41.1 (February 2020), which is 11 releases behind the most recent 1.48.0 release. The older compiler's differences after 10 months include: * doesn't have subslice patterns * has `Error::description`, which has since been deprecated * doesn't have x86 CPU feature detection * lacks fix for unsound typecasts between integers and floats * lacks fix for incomplete constant propagation * doesn't let you use conditionals, loops, match, $$, or || in constant fns, or cast arrays to slices in constant fns * has less-helpful error messages and backtraces * doesn't let you implement traits on arrays with lengths >32 * has worse type inference, this (valid since 1.43.0) code doesn't compile because 0.0 and &0.0 are f64s: let n: f32 = 0.0 + &0.0; * requires you to import standard libraries to use predefined numeric constants (like MAXINT or NaN) * doesn't support Control Flow Guard on Windows * doesn't generate documentation links from classpaths (you have to write relative file paths instead) and numerous libraries being pre-stable. For code that you're writing yourself, not having these features is mostly just a quality-of-life issue: you'll have to do things that you wouldn't have to do if you had the latest compiler. For code that you're collaborating on, having an 10-months-older compiler can be a showstopper: the code might just not compile at all, and very likely the only fix will be to uninstall your system-packaged rustc and install the version from rustup. Contrast this with C/C++ development, where your system's pre-packaged compilers are much more likely to be sufficiently up-to-date. These languages are more mature than Rust: they change slower, and new features are adopted by programmers more gradually. For example, the Linux kernel only requires GCC 4.9 [1], which was released in 2013. Debian stable supplies GCC 8.3, which will probably be able to compile unmodified kernel source code for many years without being updated. [1] https://www.kernel.org/doc/html/latest/process/changes.html https://www.kernel.org/doc/html/latest/process/changes.html

lock-free 6y ago
I can contrast with C/C++ development, where C++17/20 are not available by default on many distros because package managers lag so far behind the curve and new projects get tied to outdated versions. I just don't really see this as a problem - Rust really isn't that much of a moving target, and the benefit is there is one solution to the problem: use Rustup to manage your Rust installation. That is significantly more robust than "use your package manager."