Boring tech is mature, not old

My favorite genre of this is the guys proposing Greenfield rewrites of a multi-decade old app, using some tech less than 1 year old.

Turns out brand new stuff doesn't always survive, and even if it does you don't know its tradeoffs & pain points yet.

Everything is perfect & bug-free when it has no product use.

Seen it many times, and seen the wreckage later.

> This is (…) mostly ignored by the youths.

> We’ve seen (…) and would prefer (…) making money.

You think “the youths” don’t care about making money? That’s got to be in the top two reasons why people get into coding for at least the last decade. It’s also one of the top two reasons everything is shit, too many people only care about a quick buck.

Totally agree, but how often is the young coworker using the hip new language in their position because they were told learning it was the key to getting a job in a competitive market and it is what they have to fall back on?

Somewhat similarly, I feel like the boring/mature infra often gets ripped up in favor of something hip and new by a CIO who wants a career checkmark that they "modernized" everything. Then they move on to the next company and forget the consequences of breaking what was stable.

Yes. The only wheel re-inventing I agree with is for learning purposes. I one would say rewrite SQLite, be my guest, it's a really good way to learn. But proposing it as a replacement is....bold. Might still be something to it, but that usually doesn't stem from a simple greenfield project.

A notable aspect being that grey beards have had our fill of bikeshedding and are no longer very interested in it.

We want to get the job done and get on with our lives.

Oh, and be able to meet the changes to the requirements we know will keep coming.

Three times now I've argued strenuously against using MongoDB and Elasticache as the primary data store in an app, as they will inevitably turn into relational databases.

They did.

For Mongo going to postgres went great, but for complicated reasons we're stuck with Elasticache forever on our main product.

Hot new stuff is wish fulfillment by younger devs. They know it’ll take years to catch up with what the greybeards know about Linux or databases. If ever. If someone throws a curveball in then they reason everyone is on the same page. That nobody can be much more of an expert on 2 year old tech than they are.

What they don’t understand is that after 10 or 20 years of this drama you start to realize how much of this new shit is a repetition of the shit the “old shit” replaced, but with new jargon. Similar Shit, Different Day. Progress is not a ladder in IT, it’s a spiral. The scenery is never exactly the same but it swings through the old neighborhood all the fucking time.

Eat your vegetables kid.

When I was younger and into electric guitar, I gushed over gear so much both at stores and on the internet that I forgot to actually practice playing my instruments.

I'm starting to think there should be a term like the "HN effect" where engineers start to limit test into absurdities like "show HN: I built a rust backend with an elixir front-end that's actually running doom in pdf hosted on a distributed server composed of a network of the microchips in a Saudi camel herd, get fucked nerds" it sort of lends itself to this notion that the tools matter as much as the outcome (because oh boy do we love building tools, product be damned). I mean, building tools is fun compared to sitting down in front of a client and trying to explain to someone who can't use a mouse why they can't use the top of the line 4 gb machine from the 80s isn't working.

I want to know that the software I use was crafted with free-range, grass-fed Rust.

Your drill was probably designed by an engineer under time and cost pressure, and then assembled in a factory by someone who absolutely did not care because they're thinking about going back to the sweatshop with slightly worse conditions but slightly higher pay.

Honestly, it isn't different. Engineers are just nerds who are very prone to forgetting that the user cares about results, not tech.

If my drill breaks, it doesn't become a way to access my financial/health/personal data possibly leading to a giant identity theft induced headache.

> Why is software any different?

Because software is living, often online, has various types of your and others' personal data, and usually runs on devices that you use for other things as well. The attack surface is massive, and more often than not, accessible. (Your drill might have a way to override the safety switch by soldering stuff to it, but you need physical access for that, and the reward is minimal; if you get into Equifax' publicly accessible servers, you get lots of important and lucrative data).

You might not care that your bank's website uses some obsolete Java framework with security holes, but you will care if they use it to drain your bank account. You might not care that your recipe generator app uses an old version of Jenkins for releases and doesn't do code signing, but you will if someone hacks them and releases a fake version that installs a keylogger on your machine, or exploits a bug in their backend to ship you malware that scrapes your Pictures folder with your nudes and important documents.

And on and on and on. A piece of software not updated for years, or a phone with no security updates, or with horrible legacy like Jenkins, is a security risk you as a user have to take at least some interest in. Yeah, you won't pick your bank by their tech stack, but when you see an atrocious website with UX out of the 1950s, absurd password length restrictions, broken domains/certificates/etc., you can be pretty sure their tech stack is a disaster, and maybe, you can try to avoid them.

The more SO questions / total users, the less mature is your platform.

Updates generate more bugs and more security problems than they fix, so that's not really an argument. If you've made your system sensibly, it will be immune to any security problems.

Just this week, npm rotated some keys for the first time in a decade [0] and broke all of the sites I had deployed on multiple providers using pnpm. I had three sites on digital ocean which I had to switch to npm from to fix it.

The entire is ecosystem is the definition of not-boring

[0] https://vercel.com/guides/corepack-errors-github-actions

I think it’s kind of moot to argue of over the definition, because in practice “boring” just means that someone likes something. Similar to other terms like, “best practices,” the term is now vapid. It might have at one time meant something, but is now just synonymous with “I like this.”

If you like something it’s a “best practice.” If you don’t, it’s an “anti-pattern.” If you are used to something and like it, it’s “boring.” If you are not used to something and expect you won’t like it, it’s a “shiny object.”

IME, these sorts of terms are not helpful when discussing tech. They gloss over all the details. IMO its better to recognize the various tradeoffs all languages and tools make and discuss those specifically, as these sorts of labels are almost always used an excuse to not do that.

Rails isn't boring by any definition, it's full of surprises, metaprogramming magic and DSLs and a culture that hates code comments. Plus a community that keeps changing best practices every other year.

Which doesn't mean it's bad or anything. But "boring" shouldn't be redefined to "something I like" or "something I make money with".

Fair that it is not absolute. But I wasn't trying to claim it as fully static.

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.

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

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.

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.

I ran into this mature (AND dead?) project yesterday: benchmark.js https://github.com/bestiejs/benchmark.js/

This one is actually archived last year so clearly unmaintained but so far seems to be working great. But no successor fork. I think in this case I will use it, especially because it's in test code and not product.

A metric I think is useful is responsiveness to issues. If there haven't been any recent commits and if I open the issue tracker and the maintainer hasn't even acknowledged issues that have been opened in the last 6 months, then I assume the project is no longer maintained.

In the limit, there are also many ways to debug and patch issues in closed-source projects (someting I've done once or twice myself), unless they're run through an obfuscator or something. But there's always a dividing line where "reimplementing the functionality you need yourself" is far easier than "trudging through an old codebase that's tough to even get building".

I've used Copilot to give you an example of an average front-end web development recruitment message. From personal experience, this is how it they are in 2025. At the end of the day, the work itself will consist of applying small visual customisations to an existing CMS.

"Dive headfirst into the realms of React.js, Vue.js, and Angular for mind-blowing interfaces. Unleash the raw power of Svelte and Next.js for lightning-fast performance. Style with Tailwind CSS and code with TypeScript for ultra-modern, maintainable projects. Integrate GraphQL and WebAssembly for next-level data handling and execution. Build Progressive Web Apps (PWA) and leverage Server-Side Rendering (SSR) for out-of-this-world user experiences. Embrace the Jamstack architecture and Micro Frontends for infinitely scalable, modular applications. Focus on Component-Driven Development and Headless CMS for ultimate flexibility. Create Single Page Applications (SPA) with Responsive Design and CSS-in-JS for seamless adaptability. Master State Management with Redux, MobX, or Zustand. Supercharge your workflow with Automated Testing (Jest, Cypress) and CI/CD Pipelines. Prioritize Web Performance Optimization, Accessibility (a11y), and User Experience (UX) for top-tier applications. Implement Design Systems, Code Splitting, and Lazy Loading for hyper-efficient, user-friendly experiences. Join the vanguard of front-end development and shatter the boundaries of what’s possible!"

Using Gradle is already the first mistake, had it not been for Google and their partnership with Gradle folks for Android after dropping Eclipse, and it would have fizzled alongside Grails by now.

Boring build tools on Java land would be Ant/Ivy, Maven.

Typical example, buying an SLR to use it always on auto-focus. :)