Hacker News Reader

Comment by Aloha | Hacker News Reader

I can understand eliminating CarbonLib support, though I would have made CarbonLib an optional component you needed to install on the OS a couple years ago to make it clear this was now an optional component that may no longer be supported in the near future.

I also don't get why they would eliminate all 32-bit userspace support though - like why eliminate support for 32-bit Cocoa apps, and I think Apple made a mistake here by eliminating support.

View on HN

My guess: The binary translation support they’re going to build into ARM Macs will exclusively support x64, including low-cost bridging between x64 application code and ARM64 library code.

Not to mention Apple never leaves deprecated runtimes around for more than a few years. Once 64-bit Carbon was canned the writing was on the wall.

Thats a fair idea, I believe x86-64 is less complex with fewer addressing modes than x86 is. So that makes sense.

I'm still not sure about how I feel about an ARM laptop, I'm not opposed though.

Arm architecture is rock-solid. The trick is making an ARM processor fast enough for desktop or laptop use. ARM has unfortunately been relegated to low-end devices even though the architecture could do well for high-end machines. We don't have a good interop for running x_86 or x_64 code on ARM so the compatibility isn't there for most users (like Windows 8 ARM). Linux is mostly fine on ARM if you can compile from source and you have a compiler for that given language that works for ARM.

Just to hazard a guess...

"Intel officials believe that ARM Macs could come as soon as 2020": https://appleinsider.com/articles/19/02/21/intel-officials-b...

My guess: the old fragile Objective-C runtime ABI.

They could have done a new ABI, but that'd have broken compatibility anyway...

Why is it more fragile than the same objc runtime in 64 bit?

Because the 32-bit runtime has a fragile base class problem that can’t be fixed—without breaking binary compatibility. Class instance variable layout and instance sizes in the i386 runtime are fixed; making this flexible was the major improvement introduced with the x86_64 runtime.

At what point should they drop support?

For carbonlib? No idea, now seems fine. For 32-bit cocoa apps? I see no obvious technical reason to drop support, unless I'm missing something.

I think their rationale is that they don't want to maintain 32-bit and 64-bit code forever.

But IMO, Apple should have removed Carbon last year (six years after deprecation). That would have made the removal of 32-bit Cocoa a bit less traumatic.

Even though Linux distributions have been slowly dropping support for running on 32-bit systems nobody is talking about dropping 32-bit multilib support. The cost is primarily disk space, and Apple could just make 32-bit libraries an optional download.

Making CarbonLib an optional component several years ago would have made it clearer to users that "this is going away"

“Users” don’t know what CarbonLib is. When Apple announced that they weren’t porting CarbonLib, developers knew.

Users would have noticed when Application X stopped working unless they downloaded this thing that the download page for makes very clear will be unsupported in 2 years.

Do you really think any app developer would ask the users to download a dll from the web to make their app work? They would jusr bundle it like installers bundle the Java runtime or Windows apps bundle the compatible version of msvcrt32.dll

Reply on news.ycombinator.com