5 ms·

The eternal discussion isn't about old vs new or boring vs exciting. Mature is mature regardless of age. A system that breaks when updating dependencies, intro

by vrnvu 2y ago

The eternal discussion isn't about old vs new or boring vs exciting. Mature is mature regardless of age. A system that breaks when updating dependencies, introduces unexpected behaviour through obscure defaults, forces you to navigate layers of abstraction isn't mature... (looking at you Spring and Java ecosystem), it's old and unstable. Stability, predictability, and well-designed simplicity define maturity, not age alone. Is Python mature and boring? With toolchain issues and headaches of all kinds... Newer languages like Go or Rust i.e solve all these toolchain issues and make it truly boring in the best way possible.

zozbot234 2y ago
Go and Rust are only "boring" if you vendor all your 0.x.y -versioned dependencies (or even worse, dependencies where the "version" is just the latest git commit to trunk) and carefully vet every single update for breakage.
- skydhash 2y ago
  The nice thing about Go (compared to NPM) is that a lot of those libraries are just nicer APIs for the standard libraries and not some core tech you need. You can go for the 0.x version with the absolute assurance that you can fork it or vendor it with minimal cost in support time.
  - gf000 2y ago
    Or maybe they could have made the standard lib better, then? There is zero point to such a "dependency".
- pkolaczk 2y ago
  In my experience I had fewer problems with 0.x dependencies in Rust than with some mature 35.x dependencies in Java.
- mybazongas 2y ago
  I'm sorry, nothing is mature or stable about a language whose package manager is GitHub.
deleted 2y ago
[deleted]
grandempire 2y ago
(Genuine question). I only occasionally write python, but I just use venv and install requirements file. What toolchain challenges are out there for python?
- hylaride 2y ago
  For a large enough project, the dependency conflicts can get extremely frustrating, especially when it's time to update them. You may need to upgrade a dependency for security reasons cough cough requests cough cough, but some other dependency that calls it has pinned another version (range).
  - grandempire 2y ago
    Yeah that is a nightmare. But isn’t that a problem on all package systems except more dynamic runtimes like NPM which can load many copies of the same library?
    - hylaride 2y ago
      It's a problem all languages have, but some are better at sorting it out. The way NPM does it solves one issue, but causes others. The big issue, IMHO, is that when you're dealing with interpreted languages it's very hard to lock down issues before runtime. With compiled or statically typed languages you tend to know a lot sooner where issues lie. I've had to update requests to deal with certificate issues (to support more modern ciphers/hashes etc) but I won't know until runtime if it even works.
      - grandempire 2y ago
        Agreed. I am not saying NPM is better, just that it side steps dependency resolution problems through its runtime. (I do not want 20 copies of the same library in my process)
  - bigtimesink 2y ago
    Dependency conflicts become an issue for large projects in any language. It's less of a problem when the language's runtime is feature-rich since libraries will be less likely to use a third-party HTTP client. You can choose libraries with fewer dependencies, but that only gets you so far. At some point, you can put the libraries in you monorepo, but upgrades come with a large cost.
superkuh 2y ago
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
gf000 2y ago
Calling one of the most commonly used backend frameworks "old and unstable", when half of the internet runs on it is just...

by vrnvu 2y ago

zozbot234 2y ago

Go and Rust are only "boring" if you vendor all your 0.x.y -versioned dependencies (or even worse, dependencies where the "version" is just the latest git commit to trunk) and carefully vet every single update for breakage.

skydhash 2y ago
The nice thing about Go (compared to NPM) is that a lot of those libraries are just nicer APIs for the standard libraries and not some core tech you need. You can go for the 0.x version with the absolute assurance that you can fork it or vendor it with minimal cost in support time.
- gf000 2y ago
  Or maybe they could have made the standard lib better, then? There is zero point to such a "dependency".
pkolaczk 2y ago
In my experience I had fewer problems with 0.x dependencies in Rust than with some mature 35.x dependencies in Java.
mybazongas 2y ago
I'm sorry, nothing is mature or stable about a language whose package manager is GitHub.

deleted 2y ago

[deleted]

grandempire 2y ago

(Genuine question). I only occasionally write python, but I just use venv and install requirements file. What toolchain challenges are out there for python?

hylaride 2y ago
For a large enough project, the dependency conflicts can get extremely frustrating, especially when it's time to update them. You may need to upgrade a dependency for security reasons cough cough requests cough cough, but some other dependency that calls it has pinned another version (range).
- grandempire 2y ago
  Yeah that is a nightmare. But isn’t that a problem on all package systems except more dynamic runtimes like NPM which can load many copies of the same library?
  - hylaride 2y ago
    It's a problem all languages have, but some are better at sorting it out. The way NPM does it solves one issue, but causes others. The big issue, IMHO, is that when you're dealing with interpreted languages it's very hard to lock down issues before runtime. With compiled or statically typed languages you tend to know a lot sooner where issues lie. I've had to update requests to deal with certificate issues (to support more modern ciphers/hashes etc) but I won't know until runtime if it even works.
    - grandempire 2y ago
      Agreed. I am not saying NPM is better, just that it side steps dependency resolution problems through its runtime. (I do not want 20 copies of the same library in my process)
- bigtimesink 2y ago
  Dependency conflicts become an issue for large projects in any language. It's less of a problem when the language's runtime is feature-rich since libraries will be less likely to use a third-party HTTP client. You can choose libraries with fewer dependencies, but that only gets you so far. At some point, you can put the libraries in you monorepo, but upgrades come with a large cost.

superkuh 2y ago

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

gf000 2y ago

Calling one of the most commonly used backend frameworks "old and unstable", when half of the internet runs on it is just...