Comment by mumblemumble | Hacker News Reader

Comment by mumblemumble | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com