5 ms·

Rust – Reducing support for 32-bit Apple targets

32 points by pietroalbini 7y ago

dijit 7y ago
Seems fair. Dropping support doesn’t mean it won’t work anymore. Just that it’s not as tested (reading the RFC). 32bit MacOS was never used on x86 as far as I know. And even PPC 32bit was a very small number of machines a very long time ago. Not sure about 32bit iPads and iPhones. But, I’ve never seen a project using rust on iOS. Does anyone have an example of this?
- berkut 7y ago
  OS X Lion was the first version to use an x64 kernel, and there were definitely x86 (32-bit) versions of the OS and apps. In particular, the quicktime runtime / codecs (until quicktime x) was only x86, and various VFX apps on OS X had to write RPC code to communicate with it as a 32-bit process from 64-bit land.
- vlovich123 7y ago
  32-bit Apple mobile devices stopped with the launch of iPhone 5s (~5 years ago). Apple dropped support for 32-bit only desktop CPUs ~7 years ago (Lion) and 32-bit only mobile CPUs ~2 years ago (iOS 11). Apple dropped support for 32-bit apps completely in iOS 11 and in macOS 10.15 (this latest release). TLDR: No recent Apple OSes support running 32-bit at all.
  - kohtatsu 7y ago
    FWIW the iPhone 5s was September 2013, i.e. 6.25 years ago. I only mention it because the timing was a surprise to everyone in the industry.
  - oarsinsync 7y ago
    > TLDR: No recent Apple OSes support running 32-bit at all. macOS Mojave 10.14 (released 2018) supports running 32-bit apps. iOS 10 (released 2016) supports running 32 bit apps. I would agree that iOS 10 is not recent, in the context of the iOS timeline. I would disagree that macOS Mojave is not recent, given that Apple still has numerous show-stopper bugs in the upgrade process to Catalina.
- steveklabnik 7y ago
  Cloudflare’s 1.1.1.1 app uses Rust, on both iOS and Android. (I work there but not on it.)
  - dijit 7y ago
    Oh interesting. I wonder what the workflow actually is for that then. I guess it’s not open source. :(
    - steveklabnik 7y ago
      The app isn’t, but the rust bit is: https://github.com/cloudflare/boringtun https://github.com/cloudflare/boringtun The workflow shouldn’t be anything too intense, you build a library, compile to the right arch, and treat it like any C library.
- jbtule 7y ago
  Yeah there was one generation of Mac's that used the Intel Core Duo which 32bit only. They are long not supported. https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/m...
- jbott 7y ago
  PPC 32 bit is still used extensively in the embedded space. It's understandable that it's not the main target for newer languages as LLVM support seems to be sparse (and practically non-existent for some dialects such as Freescale PPC-VLE) but it would be great to enable safer embedded development.
- unlinked_dll 7y ago
  There’s a non trivial amount of 32 bit audio processing code for MacOS in the wild due to the longevity of snow leopard among professionals.
_bxg1 7y ago
People have complained a lot about this decision by Apple, but I respect it. They're using their leverage over the ecosystem to cut off a huge piece of cruft from not only their own codebase, but many other codebases like Rust's that can now point to their decision in the face of criticism. And the only cost is that old binaries (not old code, old binaries) will no longer run without being rebuilt. Plus, this will probably never need to happen again because 64 bits can address 18 million terabytes of main memory.
- sherincall 7y ago
  > And the only cost is that old binaries (not old code, old binaries) will no longer run without being rebuilt. Not always true. There's plenty of 32bit code that can't trivially be ported over to 64bit, even if you have the full source for all the dependencies. e.g. maybe the file formats have padding or pointer width assumptions - now you need a compatibility shim whenever loading/saving the files. Maybe the code has implicit padding assumptions, which are not documented anywhere - now you'll get occasional random functionality bugs that are a huge effort to catch and debug. It is not always a matter of flipping a compile-time switch for the developers, even if they are still around, and have all the source, and all the libraries and whatnot.
- Waterluvian 7y ago
  I feel embarrassed asking this, but better that than not to. Is memory address space literally the _only_ difference between 32 and 64 bit architectures?
  - _bxg1 7y ago
    I'm not an expert, but technically what it defines is the size of a "word", which is a basic unit of memory handled by the processor, used for - among other things - addresses. I think this might affect number precision too but I might be wrong. But regardless, most higher-level languages don't care about word size. Even C/++ code can be written such that it doesn't care about word size, though it can also be written such that it does.
  - oopydoopy 7y ago

32 points by pietroalbini 7y ago

Seems fair. Dropping support doesn’t mean it won’t work anymore. Just that it’s not as tested (reading the RFC). 32bit MacOS was never used on x86 as far as I know. And even PPC 32bit was a very small number of machines a very long time ago. Not sure about 32bit iPads and iPhones. But, I’ve never seen a project using rust on iOS. Does anyone have an example of this?

berkut 7y ago
OS X Lion was the first version to use an x64 kernel, and there were definitely x86 (32-bit) versions of the OS and apps. In particular, the quicktime runtime / codecs (until quicktime x) was only x86, and various VFX apps on OS X had to write RPC code to communicate with it as a 32-bit process from 64-bit land.
vlovich123 7y ago
32-bit Apple mobile devices stopped with the launch of iPhone 5s (~5 years ago). Apple dropped support for 32-bit only desktop CPUs ~7 years ago (Lion) and 32-bit only mobile CPUs ~2 years ago (iOS 11). Apple dropped support for 32-bit apps completely in iOS 11 and in macOS 10.15 (this latest release). TLDR: No recent Apple OSes support running 32-bit at all.
- kohtatsu 7y ago
  FWIW the iPhone 5s was September 2013, i.e. 6.25 years ago. I only mention it because the timing was a surprise to everyone in the industry.
- oarsinsync 7y ago
  > TLDR: No recent Apple OSes support running 32-bit at all. macOS Mojave 10.14 (released 2018) supports running 32-bit apps. iOS 10 (released 2016) supports running 32 bit apps. I would agree that iOS 10 is not recent, in the context of the iOS timeline. I would disagree that macOS Mojave is not recent, given that Apple still has numerous show-stopper bugs in the upgrade process to Catalina.
steveklabnik 7y ago
Cloudflare’s 1.1.1.1 app uses Rust, on both iOS and Android. (I work there but not on it.)
- dijit 7y ago
  Oh interesting. I wonder what the workflow actually is for that then. I guess it’s not open source. :(
  - steveklabnik 7y ago
    The app isn’t, but the rust bit is: https://github.com/cloudflare/boringtun https://github.com/cloudflare/boringtun The workflow shouldn’t be anything too intense, you build a library, compile to the right arch, and treat it like any C library.
jbtule 7y ago
Yeah there was one generation of Mac's that used the Intel Core Duo which 32bit only. They are long not supported. https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/m...
jbott 7y ago
PPC 32 bit is still used extensively in the embedded space. It's understandable that it's not the main target for newer languages as LLVM support seems to be sparse (and practically non-existent for some dialects such as Freescale PPC-VLE) but it would be great to enable safer embedded development.
unlinked_dll 7y ago
There’s a non trivial amount of 32 bit audio processing code for MacOS in the wild due to the longevity of snow leopard among professionals.

_bxg1 7y ago

People have complained a lot about this decision by Apple, but I respect it. They're using their leverage over the ecosystem to cut off a huge piece of cruft from not only their own codebase, but many other codebases like Rust's that can now point to their decision in the face of criticism. And the only cost is that old binaries (not old code, old binaries) will no longer run without being rebuilt. Plus, this will probably never need to happen again because 64 bits can address 18 million terabytes of main memory.

sherincall 7y ago
> And the only cost is that old binaries (not old code, old binaries) will no longer run without being rebuilt. Not always true. There's plenty of 32bit code that can't trivially be ported over to 64bit, even if you have the full source for all the dependencies. e.g. maybe the file formats have padding or pointer width assumptions - now you need a compatibility shim whenever loading/saving the files. Maybe the code has implicit padding assumptions, which are not documented anywhere - now you'll get occasional random functionality bugs that are a huge effort to catch and debug. It is not always a matter of flipping a compile-time switch for the developers, even if they are still around, and have all the source, and all the libraries and whatnot.
Waterluvian 7y ago
I feel embarrassed asking this, but better that than not to. Is memory address space literally the _only_ difference between 32 and 64 bit architectures?
- _bxg1 7y ago
  I'm not an expert, but technically what it defines is the size of a "word", which is a basic unit of memory handled by the processor, used for - among other things - addresses. I think this might affect number precision too but I might be wrong. But regardless, most higher-level languages don't care about word size. Even C/++ code can be written such that it doesn't care about word size, though it can also be written such that it does.
- oopydoopy 7y ago