He has a strong opinion, but he hasn't lost the plot. It's very reasonable to say you need to develop on the architecture you wanted to deploy to. If you want to be efficient, so most companies are going to deploy to architecture they have locally.

But you're taking comments from 2019. Nowadays lots of Mac developers develop directly on arm. So by his own argument, those Mac developers would be more comfortable deploying to an arm-based architecture cuz the running on an arm-based architecture.

So broadly I agree with him, or his past comments from 2019, you're going to need local developer environments, before you're going to get efficient server software

As someone dealing with enterprise software for living, what he's saying absolutely makes sense, and I deal mostly in web applications (where I never really have to worry about the low level stuff).

Just because the top layer seems to be the same, doesn't mean the underlying ones are. There's a reason why perfect bug compatibility is a thing (or maybe, was, in RHEL ecosystem?).

Things that looks like slam dunks in theories are never such in practice. Weird bugs pop up from time to time; and believe me, they will!

It might be rare, you may only see it once or twice in a project; but when it happens, you're gonna want to be ready, or people will question your ability to do your job.

He is sort of right, back in 2019. Even then, IBM PowerPC mainframe are still thriving.

Now, new language with cross compilation with some maturity are here. Major cloud providers now have ARM base machines ready, even designing to their own need.

ARM is in the datacenter market and become a trend.

The only thing I worried about, is the architecture of ARM are too fractured. AWS Graviton might behave differently than Ampere Altra, despite both have the ARM ISA.

I’ve got an ARM Mac. I’ve got ARM VPSes from Hetzner, and I’m compiling native code for the server.

It’s definitely easier to develop, build, and test on the same architecture, than to deal with cross-compilation and emulation.

So I think Linus is right.

JavaScript and TS are script languages with little to nothing to do with threading

The luxuries you have to not know a thing about enterprise grade servers because your world is JavaScript was made possible, and continues to be made possible, by people working on layers that do require familiarity with the underlying hardware.

X86 and AMD64 based stuff is fairly standard in terms of a motherboard with a BIOS/UEFI and peripheral busses. ARM has for a long time been kind of a mess in this regard, and there are several varieties of ARM architecture that don't play nicely with code compiled for others.

Don't get me wrong. ARM can be great for certain types of workloads. It's typically more efficient at lower power than X86, and better at various types of math. That's why we DO see it available on ARM for certain stuff like Lambda functions, but you probably won't be running full VM environments on it.

Last: notice how it's been hard to find certain varieties of Pi and various other stuff running ARM? There's shortages all over the place but I'm general Intel and AMD have been able to apply demand for their CPU's.

Yes, devs aren't tied to hardware, but there are efficiencies of scale to consider

It's tough to debug issues when you can't run on the same hardware directly.

There's a reason that arm support in open source software has exploded in the past few years, and it's because of apple silicon.

I'll agree that it's easier now, with most developers using higher level runtimes, but someone's got to get those runtimes working, and it's much easier to develop if you have a laptop running that hardware.

The linked message is from 2019, i.e. per-M1 Apple laptops and at a time when arm in datacenter was just starting out.

Tbh, I feel like it's kinda pointless to discuss a comment made by someone over 4-years ago. Both the environment and the person itself can change a lot in that time.

"The software development market evolved from C to very high language languages such as Javascript/Typescript and the majority of stuff developed is done or will be done in those languages thus the CPU architecture becomes irrelevant."

I saw someone else make a similar comment about C. People track these things, and C has been in the top 2 most widely used languages for more than 2 decades. Not knowing this should probably make you wonder why your background has resulted in such a narrow experience.

https://en.m.wikipedia.org/wiki/TIOBE_index#

From what I learned at university:
CISC instruction set (x86) was developed to adress the technical reality of its time - time costly CPU operation and fast read from storage. Not long after that the situation has changed - storage reads became slower in comparison to computing time (putting it simply it's faster to read an archive and unpack it than to read unpacked thing). But in the meantime the PC boom has happened. In a way backward compatibility and market inertia locked us with instruction set that is not the best optimised for our tech, despite the fact that RISC (for example ARM) was conceived earlier.

In a way software (compilers and interpreters too) is like a muscle. The more/wider it's used, the better it becomes. You can be writing in python but if your interpreter has some missed optimization opportunities, your code will be running faster on architecture with a better optimized interpreter available.

From personal observations:
The biggest cost of software is not to write something super efficient. It's maintainability (readability and debugging), ease of use (onboarding/training time) and versatility ("let's add the feature that is missing to what we have, instead of reinventing the wheel and maintaining two toolsets").

The new languages are not created because they can do something faster than assembler (they can't, btw). If assembly code is written as optimal as possible, high level languages can at best be as fast. Writing such assembly is a problem behind the keyboard, not a technical limitation. The only thing high-level languages do better is how much time it takes a human to work with it.
I would not be surprised to learn that bigger part of these big bucks you mention go not into optimization but rather into "how can we work around that difference so the high-level interface stays the same as for more widely used x86?"

In the end it all boils down to machine code - it's the only thing that really exists when it comes to executing code. If your "human to bits translator" produces unoptimized binaries, it doesn't matter how high-level your code was written in.
And sometime in the meantime we've arrived at a level when even a few behemoths like Google or Microsoft throwing money into research (not that I believe they are doing so when it comes to optimization) is enough.
It's the field use that from time to time provides a use-case that helps finding edge-case where optimization can be made.
To purposefully find it? Dumping your datacenter in liquid nitrogen might be cheaper and probably more predictable.

So yeah, I mostly agree with him.
Maybe the times have changed a little, the thing that gave RISCs the most kick were smartphones, then one board computers, so not long ago. The improvements are always bigger at the beginning.
But the fact that some companies are trying to get RISC back into userland in my opinion means that the computer world has only started to heal itself after the effects of PC boom. There's around 20 year difference where x86 was the main thing and RISC was a niche