3 ms·

Rust is the opposite of mature in practice. A language can be mature but if the style of devs that chose to write in it aren't, on average, then it doesn't matt

Rust is the opposite of mature in practice. A language can be mature but if the style of devs that chose to write in it aren't, on average, then it doesn't matter. Sometimes old versus new effects this. For example in Rust the language improves so fast I've literally had a 3 month old rustc be unable to compile a rust program (SDR FFT thing) because it used a new feature my 3 month old rustc didn't support. As I continued to encounter Rust projects this happened a few more times. Then I decided to stop trying to compile Rust projects. Right now the dev culture is mostly bleeding-edge types who always use the latest version and target it. As Rust becomes more generally popular and the first-adopter bleeding-edge types make up proportionally less of the userbase I expect this will happen less. Bash still gets new features added all the time too; it's just that the type of developers who chose to write in Bash care about their code being able to work on most machines. Even ones years (gasp!) out of date.

LinXitoW 2y ago
Is there a good reason to not just use the rust version the project is made for? I have some Java projects using the newest 21 version, and older ones using 8.
- superkuh 2y ago
  Yes, I don't curl|sh like recommended for my rustc or otherwise install random arbitrary compilers from outside of my OS repositories. I have an OS install with system libraries and programs and I want to use that. I don't have to set up a custom install of a language for every single application for any other language (although python in machine learning domain is getting there). This is an abnormallity which complicates software mantainence and leads to problems. It should be avoided if possible. And setting up container for every application is also not a solution. It's a symptom. Like a fever is a symptom of infection, containers are symptom of development future shock. To be clear, I'm talking about in the context of a human person and a desktop computer. Not employed work at a business.
  - nicoburns 2y ago
    You can install `rustup` using your system package manager if you really want to. You could also `curl | manually-verify-script | sh`. But if you don't stick to recommended install procedure then of course you are stepping out of the "boring" path. > I don't have to set up a custom install of a language for every single application for any other language Which languages do you use? I find that using version manager saves a lot of headaches for every language that I use, and is very much a normality. Otherwise I run into issues if I need different versions for different projects. The fact that Rust has a first-party version manager is a blessing.
    - superkuh 2y ago
      rustup still is outside of repos even if the download method isn't silly and insecure. For some random applications that's fine, but for a compiler and toolchain? No. If I wanted a rolling distro I'd use a rolling distro. Rust culture only being compatible with rolling is not a good thing for many use cases. >Which languages do you use? c, c++, perl, bash. A program written in perl+inline c today will compile and run on system perl+gcc from 2005. And a perl+inline c program written in 2005 will compile and run just fine on system perl+distro today. And pure Perl is completely time/version portable from the late 90s to now and back. No need for containerization or application specific installs of a language at all. System perl just works everywhere, every time. There are versions of c++xx isms and non-c89/etc isms in some programs written in these languages. But at least these only happen a couple times a decade and because of the wide popularity and dev culture their use is much more delayed after introduction than in rust or python.

LinXitoW 2y ago

Is there a good reason to not just use the rust version the project is made for? I have some Java projects using the newest 21 version, and older ones using 8.

superkuh 2y ago
Yes, I don't curl|sh like recommended for my rustc or otherwise install random arbitrary compilers from outside of my OS repositories. I have an OS install with system libraries and programs and I want to use that. I don't have to set up a custom install of a language for every single application for any other language (although python in machine learning domain is getting there). This is an abnormallity which complicates software mantainence and leads to problems. It should be avoided if possible. And setting up container for every application is also not a solution. It's a symptom. Like a fever is a symptom of infection, containers are symptom of development future shock. To be clear, I'm talking about in the context of a human person and a desktop computer. Not employed work at a business.
- nicoburns 2y ago
  You can install `rustup` using your system package manager if you really want to. You could also `curl | manually-verify-script | sh`. But if you don't stick to recommended install procedure then of course you are stepping out of the "boring" path. > I don't have to set up a custom install of a language for every single application for any other language Which languages do you use? I find that using version manager saves a lot of headaches for every language that I use, and is very much a normality. Otherwise I run into issues if I need different versions for different projects. The fact that Rust has a first-party version manager is a blessing.
  - superkuh 2y ago
    rustup still is outside of repos even if the download method isn't silly and insecure. For some random applications that's fine, but for a compiler and toolchain? No. If I wanted a rolling distro I'd use a rolling distro. Rust culture only being compatible with rolling is not a good thing for many use cases. >Which languages do you use? c, c++, perl, bash. A program written in perl+inline c today will compile and run on system perl+gcc from 2005. And a perl+inline c program written in 2005 will compile and run just fine on system perl+distro today. And pure Perl is completely time/version portable from the late 90s to now and back. No need for containerization or application specific installs of a language at all. System perl just works everywhere, every time. There are versions of c++xx isms and non-c89/etc isms in some programs written in these languages. But at least these only happen a couple times a decade and because of the wide popularity and dev culture their use is much more delayed after introduction than in rust or python.