But I know a lot of people still run Windows because they want the Windows version of an app, either because it isn't available at all on Mac or just because the Windows version runs better (Excel was a classic example of this for a long time, might still be). In that case, I don't know if that same translation layer will have the same performance (if it can run at all outside of MacOS) when running an entirely different OS.
I think this is called "transpiling" -- a version of compiling that's mainly translating from another architecture. And it didn't sound from their description like it was JIT -- it sounded like it would do the transpile when you first installed it (or maybe first ran it?) and keep the results.
And they have a first pass AOT, with a JIT backup from the sounds of it to support JITs like browsers, node, and java.
VS is not even 64-bit yet...
[0]: https://github.com/VSCodium/vscodium/releases/tag/1.46.1 (basically just MS source minus branding)
VS Code was expected to run on anything, being nothing more than Javascript & HTML wrapped via Electron.
Of course VS Code works on ARM, it's an electron app.
(I recently tried to install Zoom on arm64 Debian and it didn’t go so well... Rstudio wasn’t even close to an option)
Zoom, Bluejeans, Dropbox, pretty much all the popular apps I used where I could find a Linux version for my Dell laptop, I couldn't find a way (though got close at least, with Dropbox) to run them on an ARM64 CPU.
Lots of games work fine with it too: https://www.youtube.com/watch?v=z-4aGNqZ724
This announcement is the final nail in the coffin I suppose. I hope some company will come out with great quality, well-designed, minimal laptops. That run Linux perfectly.
Many people who want dual boot Windows/ Macs want them for games and gamers want the sort of performance you don't get with emulation.
Windows has always been cross-platform, x86, MIPS, Alpha and PPC back in the day. There was even a SPARC build at one point.
I suspect developers running VMs with Linux on them is far more common than developers running Windows VMs. Likely by an order of magnitude. Web developers want Linux VMs, Windows developer have Windows laptops.
Sure, but the number of people writing cross platform apps is a small fraction of the number of web developers out there.
Additionally, there's the Android/iOS crowd in the same boat, where emulation of non x86 in Android dev is pretty limited (but I can see that being rectified with the newer virtualization extensions).
You mean that they opened and could run a command line app? I'm not actually sure they implied it was x86.
In this case, I don't think the first ARM Macs will have undesirable hardware ala the first few years of Touchbar Macs, but there will be some straggler software whose ARM ports will be delayed or will never happen. For those who depend upon that software, the final Intel Macs will be invaluable.
To put it a different way: the initial sales of the ARM-based chips won't be as strong as you think they might be, or as wide spread.
Having both Intel and ARM based systems in the market will even out the sales.
History is repeating itself, it's worth reviewing the previous transitions before making assumptions.
- https://everymac.com/mac-answers/macintel-faq/why-did-apple-...
- https://en.wikipedia.org/wiki/Apple%27s_transition_to_Intel_...
- https://tedium.co/2020/06/16/apple-powerpc-intel-transition-...
I think quite a few developers would be happy to use the same basic software stack on on a phone app and a laptop app.
Now, though, suddenly I need to figure out how NEON works if I want to continue to support professional users on MacOS. I need to increase my hardware costs to ensure adequate test coverage. I need to use something other than Intel's glorious VTune for profiling & optimization. When I'm step-debugging my C++ or assembly tight-loops, I need to know double the amount of assembly than I do today. I need to learn ARM's memory model & cache behaviors.
If I'm just writing some silly native app that could have been a website as is trendy then yeah this is all no big deal, who cares? But if you're really pushing professional app boundaries, where time is money? That's a different story.
Just because your use case is different from those who have C or C++ code and a good optimizing compiler doesn't mean you need to disparage every other type of developer on the planet.
There are a lot of people who write native ARM for phones and tablets for performance purposes, too. Some of them get down into ARM assembly. If they port to Intel and want to do assembly-level things there, they need to learn twice as much assembly coming the other direction.
Is the future more like Intel desktops or more like ARM-based mobile devices? If you think the latter then Apple is definitely moving towards where people will be (insert Gretzky quote: "skate to where the puck is going to be, not to where it has been.)
Apple's focus has always been the consumer market, and for most consumers, they're not likely to notice the platform change.
One might say, Apple gained a huge developer demographic when it moved to x64 from PowerPC, won't this matter to them? But most of those developers were creative types that don't work at the binary level anyway. If you're doing front-end web dev on VS Code and almost never fire up gcc/clang, your life isn't going to be impacted significantly.
Those whose lives were impacted (e.g. scientific computing folks who struggled to get certain Linux-specific software to compile on what was a BSD-ish platform) have probably moved off the Apple platform and on to Intel Linux years ago or at least they're likely to be running a Linux VM on their Macbook Pros. (homebrew doesn't really cut it)
Also unlike back in the day when most people were still running desktop apps, so much of what we do on a daily basis is on the browser nowadays. Calendar? Cloud-based. Email? Cloud-based. Word processor/spreadsheet/presentation? Cloud-based -- and Microsoft Office is being ported to ARM. We're living in much more platform-agnostic world than we were even 10 years ago.
I expect the x64 to ARM transition to be seamless to most people who are currently on the macOS platform.
A bunch of Python wheels might need to be recompiled though.
I completely agree with you IF Apple contains this to just the Macbook market. If they push this to iMac Pro / Mac Pro, too, though? Or even Macbook Pro? That's a different story. For developers it probably won't matter much, but for users currently relying on things like Protools to make a living? There's a good chance this won't be a friendly transition to them in the short term.
If not, there will be Universal 2 binaries with both x64/Intel binaries for a while and an emulation mode for legacy binaries. Underoptimized at first? Maybe, but they work well enough and performance catches up eventually -- the transition is over 2 years. Same situation as before. Software that work will continue to work on existing and new hardware for a while. Nothing is going to stop working the moment the new processors come out.
We've seen all this happen before (m68k - PowerPC - Intel). And it's really not a problem.
Apple released a bunch of PPC Macs after they announced the switch to Intel, so this isn't unprecedented.
They're just trying not to Osbourne themselves too badly. They want you to keep buying Intel Macs, but who's to say how long they'll keep support.
Apple announced the PPC in 1994 and sold new 68K Macs for 3 years at least.
I am pleased I didn't splurge for the 32GB of RAM, however. I'll do that with my next one.
(that probably totally depends on whether Intel actually designs a desktop chip for the first time in nearly two decades, rather than continuing with their current sell server chips as poorly designed desktops path)
They aren’t rushing x64 out the door.
Much like the 2015 Macbook Pro I expect you'll be able sell it for more than you paid for it years later.
Apple was already grumpy about servicing it by 2018 or so though, even with AppleCare. (I've switched to Windows now.)
It's still as powerful as any of the current Apple laptops - progress has been slow these last 6 years.
It may depend on one's definition of "limited": the Rosetta was first released with Mac OS 10.4 in 2005, [1][2] and was last available in Mac OS 10.6, which first released in 2010, [3] but whose last update was in 2011.
Six years of transitional support is not unreasonable.
[1] https://en.wikipedia.org/wiki/Rosetta_(software)
New software will be cross-compiled with both instruction sets: