lysdexic

That should be a disciplinary issue.

And that's how you get teams to stop collaborating and turn your work environment to shit.

This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.

I doubt that by now the concept of TDD is unheard of to any professional team. Name-dropping concepts actually contributes to loose credibility of any code quality effort, and works against you.

Also, TDD's credibility is already low as it piles on the requirement of spending unordinate amounts of extra work effort on aspects of a project which don't deliver features, and thus it's value-added is questionable from a project management perspective.

One aspect that does work is framing the need for tests as assurance that specific invariants are verified and preserved, and thus they contribute to prevent regressions and expected failure modes. From my experience it's far easier to sell the need for specific tests if they are framed as "we need assurances that this component does not fail under conceivable usecases" and specially as "we were screwed by this bug and we need to be absolutely sure we don't experience it ever again."

Here's a way to convince a team to write unit tests:

• setup a CICD pipeline,
• add a unit test stage,
• add code coverage calculation,
• add a rule where unit tests fail if a code coverage metric drops.
• if your project is modularized, add pipeline stages to build and test and track code coverage per module.

Now, don't set the threshold to, say, 95 %. Keep it somewhat low. Also, be consistent but not a fundamentalist.

Also, make test coverage a part of your daily communication. Create refactoring tickets whose definition of done specifies code coverage gains. Always give a status report on the project's code coverage, and publicly praise those who did work to increase code coverage.

(proceeds to cry and click on "subscribe")

So, you still have to go through all the dependencies, vulnerabilities and incompatibilities.

That's the point. There is no free lunch. Yet, you can live with stable, pinned versions and only upgrade the ones you really need to, and that means exercise your personal criteria instead of mindlessly upgrade everything just because there was a bump in a version number somewhere in an upstream dependency.

Yes, you can now kind of control the timing,

Timing, extent, scope, and impact. That's the point.

but it’s still unacceptable in my opinion, that you have to spend so much time just to not be an active danger to everyone.

You only spend the time you decide to spend. There are already vulnerability scanners that pinpoint exactly which versions need to be updated, and do that automatically for you. Mindlessly opening the floodgate to each and every change is by definition idiocy and a liability.

Then you’ll end up with tons of vulnerabilities within days.

You only end up with vulnerabilities if you refuse to update your dependencies. Updating a dependency is something you need to do yourself, along with running build validation tests after a successful update. Just because npm can download newer packages that does not mean those packages are good.

Something in the dependency tree will yell at you that it is deprecated or discontinued.

Only if you didn't pinned the dependencies you actually consume, and expect that all your dependencies magically comply with semver.

Blindly replacing dependency versions never worked, at least reliably. If you do not put in the work to ensure things work, more often than not you'll be surprised by them not working.

Also, double can and does in fact represent integers exactly.

There is no C++ tool (AFAIK) providing an exhaustive check of ALL the data lifetimes.

Your reply reads like an attempt at moving the goal post.

The initial point was "Sometimes it’s easier to try a new idea in a new language (e.g. the borrow checker in Rust) rather than trying to shoehorn it into an existing language", to which I pointed the fact that yes it's indeed possible to "try a new idea" like borrow checking, and it only takes adding a tool that runs in a post-build/unit test step. It's simpler, easier, and does not force anyone to rewrite projects from scratch.

Claiming "oh but it might not work as well" is not an answer or a refuttal.

There's a design pattern aptly called Parameter Object.

https://wiki.c2.com/?ParameterObject

Parameter Object is a popular solution for problems such as:

• Exploding number of function arguments. As a general rule of thumb, if you need to pass more than 3 arguments, you just extract them into a Parameter Object to handle as a single parameter.
• Combinatorial explosion of test cases. If your function supports multiple input parameters but some combinations of values are invalid/impossible/unsupported (i.e., show/hide window, full screen or windowed or minimized, etc) then instead of wasting time with branch coverage you simply extract a Parameter Object and add validation to it.

If there was a single language, afterwards the same broken logic would be applied to frameworks and libraries, and we all know how many people bitch and whine over Java and it's extensive standard library.

Rust's borrow checker is a bad example. There are already a few projects that target C++ and support both runtime and compile-time checks, not to mention static code analysis tools that can be added to any project.