I can certainly imagine a 'serverless' platform like Lambda or something where running on ARM is just an implementation detail (if it's not already).
I wouldn't be at all worried about deploying my Ruby, Python, or Java app on ARM, having worked with x86 locally.
That is, as long as the Ruby, Python, and Java development teams themselves have been able to test on ARM hardware themselves!
And then there are all the other native and system packages that you depend on. For example, I do a lot of work in Python, and I would be very hesitant to have anything but an Intel CPU in my workstation. Because that's what our servers run, and I know that a lot of packages I use include native code that has been carefully tuned for Intel CPUs. If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
That said, I'd be willing to at least try it. On the other hand, if work started talking about switching to ARM servers in production, I'd instantly be clamoring for a (non-M1) ARM workstation to develop on, because I need to know that I'm not going to get into trouble with packages that get a lot of love in the x86 versions of the native libraries but not so much on ARM.
This was a good argument a couple of decades ago. Now? Keep in mind that most devices in this planet are ARM-based, ever since we started talking about 'smartphones'. They have been running these interpreters for a long time now. Most applications and libraries of any importance have been ported.
> If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
I thought that's what staging environments were for? Plus scale tests? A laptop provides a pretty poor proxy for a server environment behavior. For starters, they are not really the same spec, are they? Are you running a Xeon-based laptop?
Or, for example, there's one library I use that includes some inline assembly language routines. Which target SSE, not SVE. So, if we're targeting different ISAs, then my dev box isn't even executing the same code as what would be running in production.
That seems crazy to me. What bizarre excuse does your organization have for that policy?
To me, part of the point of a staging environment is to provide something as close as practical to prod in which to test, reproduce, evaluate, and investigate issues, be they performance, correctness, or what have you.
Even if it were allowed, it would still be awkward. I want to, as much as is practicable, find problems as early as possible, and not wait for them to get all the way to staging. I'm not really interested in making myself less able to do my job effectively just because I can.
Nowadays a browser takes that role.
Having a workstation with the same CPU is definitly not an issue as Linus makes it to be.
Java less so, but the behavior and performance characteristics are definitely different.
I know Java has C extensions for some things too. I'm curious how much code is actually "pure Java", but I've actually rarely seen Java used at any of the places I worked at.
I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.
I develop and test against docker containers that run on a specific image + arch + base OS.
Even though my environment is supported on ARM, I am still not keen on using ARM servers even if I think it will work. There's just too much risk involved and I don't have the time to set it up and test it thoroughly.
With Python, some of the really useful libraries are written in C so you really need consistency between your environments if you don't want gotchas in your deployment pipelines.
Even more people use macbooks to develop for the browser, or to develop using platform-independent languages: Python, Ruby, Node, maybe even golang.
Quite a few people then package their backend code in a container and test it in a Linux VM which "Docker for Mac" helpfully provides.
But indeed the fact that Macs used to run on Intel, so the libraries you used in development were mostly that same versions of the same code as in production, must have been helping.
People only develop on MacOS because of how similar it is to Unix, not in spite of it. Go ahead, look at how many developers were using MacOS before OSX. I'll wait. The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
> So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
Let's clear this up: there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software. Unless you're working as a web developer (in which case, may god have mercy on your soul), you're probably going to end up using an x86 machine. Hell, my best friend is a die-hard Apple fan, and even he has admit that he can't really upgrade his Xeon iMac unless Apple offers him an upgrade within the x86 ecosystem.
There were plenty of other problems with pre-OSX MacOS.
> The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
The differences between x86 OSX and x86 Linux are bigger than the differences between x86 Linux and ARM Linux, in my experience. So these machines are also "close enough" to ARM servers.
> there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software.
Most developers have a local development environment and a separate production environment. Developers place some value on having them be similar, but they're also happy to introduce differences between local and prod for the sake of other tradeoffs.
Why can't he upgrade? (Genuine question)
From 1984 to the iPhone, I believe it was the norm to develop Mac applications on Macs, except for a brief period when the very first models were starved for memory.
It is, but it introduces enough differences that you're not "at home"; indeed I'd say OSX-to-Linux is a bigger difference for development than x86-to-ARM.
Whether you're right or not, I think I agree with the idea.
It also seems to me that, in general, working with a different CPU architecture and instruction set implies that the new & improved stuff has to be significantly better to be worth the cost and risk.
At this point, is one really that much better than another? Are large improvements happening at the margin?
Another camel that'll poke it's head in the tent, in large/expensive embedded (which I realize that the parts in the article aren't aimed at) is whether a CPU and it's battlegroup of other stuff will be supported right off the bat by software infrastructure and later on by actually being available in the long run. You have to wonder how out on a limb anyone who used a Motorola 88k felt.
For example, if I'm building on Firebase with Cloud Functions I'm so far abstracted from the underlying hardware that these architecture specific issues are less important.
Similarly, if I'm working in Django/Python on AWS RDS, using an ARM server for my EC2 instance might be an issue ... but moving my RDS Postgres instance onto ARM might not make a difference.
I have no specific knowledge here but I imagine the x86-64 builds are far better tested, regarding correctness. As cmrdporcupine points out, the performance of the x86-64 builds will also have been better studied. Whether it's an issue in practice, I don't know, but if you're looking to minimize risk, there are good reasons to stick with x86-64.
Most web stuff dont deploy on x86, they deploy on VM or more specifically JVM. Which is someone else's problem. Amazon and Oracle are both spending resource making sure it works flawlessly.
I mean seriously, most doing Web Development dont even want to touch the VM.
You may want to ask Amazon, who is trying to get as many Graviton 2 produce as possible from TSMC because the demand for them are outstripping supply.
And all of that was before Apple even announced their switch to ARM on Mac.
For some workload it is half the cost on R6g than x86 instances. And for some like Twitter, they will invest into making sure it works with ARM. Those works get filter down the pipe. Medium-Large size companies see ecosystem matures and clear cost benefits they will move.
"I can pretty much guarantee that as long as everybody does cross-development, the platform won’t be all that stable. Or successful.
Some people think that “the cloud” means that the instruction set doesn’t matter. Develop at home, deploy in the cloud.
That’s bullshit. If you develop on x86, then you’re going to want to deploy on x86, because you’ll be able to run what you test “at home” (and by “at home” I don’t mean literally in your home, but in your work environment).
Which means that you’ll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better…
Which in turn means that cloud providers will end up making more money from their x86 side, which means that they’ll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).
Guys, do you really not understand why x86 took over the server market?
It wasn’t just all price. It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over. (All emphasis original)"