Why the need for "higher innovation velocity" in a programming language as if it was an end by itself?

A stable well-defined language is good, as it allows multiple compiler/interpreter implementations, and the code will run unchanged for many decades. How old is the average COBOL code? 40-50 years old? Isn't it wonderful that code that old still runs?

Python is one of those "innovating" languages.

The language is constantly in flux, forcing code rewrites of perfectly good code because the Python language maintainers get bored and break syntax that was valid five years ago. No, they don't just add features, they also remove features.

Every year they publish a porting guide for migrating from python 3.x to 3.(x+1) and they stop supporting 3.(x-4).

So every year, many projects break, many language tutorials need to be updated, all PyPi libraries need a look, all of this in the name of "innovation" which is more often than not superfluous crud and syntactic sugar plus removal of features the language maintainers got bored of.

Losing all the working code that was written in python2 and was never ported to python3 was worth it, really?

The many million man-hours spent porting python2 code to python3 code was money well spent?

Sure, there are ways around this; for instance older C/C++ language source code can often be compiled with a specific flag, such as -ansi or -std=c90, but that's more an exception than the rule. I see no such possibility in Ruby, PHP, Python, Guile, Java, and so on.

TL;DR: rewrite 50-year old COBOL code once in an "innovative language" and odds are you'll be forced to rewrite many parts of it in less than 10 years. Then less than 10 years after, and so on.

the young always win, if only because their rivals die

Had the young always won, UNIX-type systems would have been gone long ago. AFAIK most computers in the world run a UNIX-derivative, not a DOS/Windows derivative, not a BeOS derivative, not a OS/2 one, not a MenuetOS one...

And most importantly, there aren't that many complex projects in Rust. Sure, Rust aficionados can rewrite ls or grep all day long, that does not prove a very large Rust project can be maintained over a non-trivial period of time.

They sound like any new young hire that says he could rewrite the company's business-critical software in a single month using $LANGUAGE_OF_THE_DAY.

As always, remember that in IoT, the "S" stands for Security.

breaks the philosophy of each piece doing one thing and doing it well

Will you ditch the monolithic Linux kernel because it does networking, file systems, I/O scheduling, drives hardware, has crypto functions, plus so much more unrelated stuff?

The "do one thing and do it well" refers to user-space tools, not to what the kernel offers.

why isn't static linking used anymore

Because it's a good idea until you really understand the implications.

It means that all software that uses libFOO needs to be updated on every libFOO security update. Meanwhile, using a shared libFOO means updating that single shared instance updates everything that dynamically links to it.

On a system that only uses distro-created packages, no big difference apart from a pure waste of bandwidth and update time. But can you guarantee that a 3rd-party repo linking its programs with a static libFOO will update its software in a timely fashion?

As a side effect, static linking also wastes RAM, disk and CPU (which manages RAM and disk) --- having so much at our disposal doesn't mean it's infinite.

Our own stupidity and blind faith in the godlike machines certainly is capable of it though.

Indeed. My own doomsday scenario does not need metal self-awareness, it only requires some idiot programmer blindly copy-pasting some LLM hallucination into a critical code path.

There are DJs that believe, in my opinion superstitiously/pseudoeciencely, vinyl is somehow superior in sound quality.

They may be right under the right circumstances.

Vinyl has limitations digital music does not have, one of which is that you cannot violently compress the dynamic range as done with much of today's music --- the needle will skip.

So oftentimes, the master that is used for vinyl is not the same master that is used for digital. And that vinyl master has sound that breathes, unlike the digital version.

Note that if that same vinyl master was used for digital, the digital version would sound better.

Go listen to an old seventies vinyl and compare it to last years' digital remaster --- odds are your old vinyl will sound better because the new remaster was punished with over-compression.

Graveyards are filled with proprietary communication platforms that eventually screw up and die. From ICQ to Digg to Google+ to Reddit to Vine to name it. Eventually Slack, Instagram, Facebook will all follow. I'm surprised Slashdot still exists.

Meanwhile, e-mail (1971), Usenet (1980), IRC (1988), Jabber/XMPP (2004) are still alive.

Maybe it's time we realize that unless no one owns the communication platform, it's going to die sooner than later.

We see what happens with those fast-moving ecosystems like JavaScript; create a project, go for a coffee, come back, suddenly half the libraries your code is attached have "upgrades" that break your code and are incompatible with each other, forcing you to pin specific version numbers and making your whole project vulnerable as fixes are not backported.

A similar effect is bound to happen with Rust.

Rust does not currently have an official spec. And the language changes with every dot-release, every few weeks.

Maintaining a sudo/su in Rust will mean constantly adapting the code to the new Rust "standard" of the day, creating a future situation where a security fix will be written in a future version of Rust your distro will not yet support.

Can the Rustaceans get their bloody act together and create a spec _before_ meddling in core projects and imposing their half-finished language?

If you want everything free, oh well

I don't have to subsidize a broken business model with my private data, nor should you.

Nobody's forcing businesses to be on the internet. If they feel they're not getting a enough bang for the buck from their online presence, they just have to shutdown their site and move on to other avenues.

Maybe you're too young to remember, but the web was almost ad-free at first, and the few ads were static images that didn't rape privacy. E-mail service is ad-free and has been for almost 50 years.

TL;DR: The current privacy nightmare is not the only possible way to have a vibrant and valuable internet.

To many of us, baseball games are long and boring. Making it easier for batters to score would be a welcome change

You do realize that there is no clock in baseball hence all other things being equal higher scoring means longer games? They are already, on average, more than three hours long in the MLB; four-hour long games would draw in more fans, you think?

Been debunked for years. Hint: why would Egyptian coins have latin and roman numerals on them?

Yeah, closer to the metal, better CPU utilization, captain Obvious.

But as good little Rust shills, let's avoid mentioning Rust's unstable ABI, that makes shared libraries a practical impossibility.

Static linking wastes disk space and memory, meaning beefier hardware is required.

And it also means the tiniest security problem in a library involves updating all programs using that library. Hope your recompile/reinstall cycle uses zero energy!

Please don't invoke the bullshit argument "the number of vulnerabilities is severely decreased, because Rust language itself makes code secure"; sure, it may help, but for such a niche language, I find the number of Rust-related CVEs really impressive.

Person with no backup loses data. News at 11.