Hacker News Reader

Comment by vrnvu | Hacker News Reader

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.

View on HN

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.

In my experience I had fewer problems with 0.x dependencies in Rust than with some mature 35.x dependencies in Java.

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.

Or maybe they could have made the standard lib better, then? There is zero point to such a "dependency".

I'm sorry, nothing is mature or stable about a language whose package manager is GitHub.

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

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).

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.

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?

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.

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)

Everywhere I've worked, I've had a few cases where we updated some dependencies on machine A (e.g. a developer's macbook), everything ran fine, we did the same updates on machine B (e.g. an Ubuntu EC2 instance) and everything broke. This is especially case with the numpy/scipy/pandas/etc. ecosystem. In one case this took days to fix, which is insane. I haven't had that experience with any other language.

It's worth noting that all of these involved anaconda, which was the recommended way to install numeric libraries at the time. Other package managers might be better.

Native dependencies are a huge PITA depending on their nature and lack of cross-platform portability. This can and will also pop up on CI.

Well, every six months, someone finally solves Python's distribution problem.

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com