Kindasorta? Even higher level languages still rest atop the native code. For starters, someone's got to maintain the port of the interpreter or VM. It's going to get a lot more attention if developers are using it as their daily driver.

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.

> For starters, someone's got to maintain the port of the interpreter or VM

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?

It at least gets you in the same ballpark. I'm not allowed to hook a debugger up to anything in the staging environment, and it's not terribly fun to be stuck, for example, having to guess at how memory fences are behaving in production because all the machines where you can test things empirically have a different memory model.

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.

> I'm not allowed to hook a debugger up to anything in the staging environment

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.

Honestly, does it even matter?

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.

Back on the glory days of UNIX timesharing, my workstation was a thin client to the actual world.

Nowadays a browser takes that role.

Having a workstation with the same CPU is definitly not an issue as Linus makes it to be.

Ruby and Python both have significant parts of their implementation and libraries in C, so it's still a significant problem there.

Java less so, but the behavior and performance characteristics are definitely different.

Definitely. A huge chunk of Python and Ruby packages are written as "C extensions", and if those C extensions are going to get compiled on some platform the developers haven't tested them on, it will make for fun surprise bugs.

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.

That all depends on how far you trust "write once, deploy anywhere." It doesn't have a flawless track record.

I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.

One thing you might encounter is some C-binding building correctly on your machine but not in production (or vice-versa). Sure 99% of what you deploy is Python, Ruby, or JS... but that 1% in C/C++? Well.. you need that 1%.

Even if I'm using a JIT-ed product like C#/Java apps, I might still need to use OS-specific features that might differ from the ARM vs x86 flavour of Linux.

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.

Even in Python, OS differences and architecture differences pop up between testing, staging, and prod. It's annoying and can definitely cause user-facing problems.

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.