5 ms·

Be real: Apple is not going to rewrite MacOs/iOs in Swift. Objective-C will always be there, offering faster and more robust features. Just look at the Microso

by toyg 3y ago

Be real: Apple is not going to rewrite MacOs/iOs in Swift. Objective-C will always be there, offering faster and more robust features. Just look at the Microsoft equivalent: yes, C# is good and all, but the hardcore Windows apps are still using (lightly-skinned) VC++ APIs - after almost 25 years since they started flogging .NET. Swift is for the new rubes, bootcamp graduates and so on.

jshier 3y ago
They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.
- deleted 3y ago
  [deleted]
- sandyarmstrong 3y ago
  Yup, exactly. Swift was specifically designed to replace Objective-C and C++ throughout Apple codebases (see https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k). C# is a totally different story.
  - throwaway2037 3y ago
    > C# is a totally different story. Interesting. Can you share more details?
    - sandyarmstrong 3y ago
      Disclaimer: I work for Microsoft, though I wasn't there during the early days of .NET or Windows Longhorn. C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code. Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues. The difference is really about what the stated goals of the language were/are.
      - throwaway2037 3y ago
        Thank you to share. My guess: In the year 2000, it was impossible with current desktop computing power to use C# for OS internals. In 2024, it is a different story.
- toyg 3y ago
  That's what MS said as well, when they were pushing C#. All Windows will be using safe code! Still waiting... Another example is Mozilla and Rust - hell, I wouldn't be surprised if there was still Netscape code somewhere in the bowels of FF/TB! Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
- lapcat 3y ago
  > Foundation is being rewritten entirely in Swift. That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple). > All new code is in Swift. False. > All new frameworks are Swift-only. False.
  - jshier 3y ago
    > That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple). It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong. My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
    - lapcat 3y ago
      > It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong. Which assertion was wrong? I was paraphrasing from the project page itself: "It is in its early stages with many features still to be implemented." https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation
      - jshier 3y ago
        > Which assertion was wrong? Your original assertion that Apple wasn't rewriting anything.
        lapcat 3y ago
        > Your original assertion that Apple wasn't rewriting anything. I have no idea what you're talking about. I made no such assertion. Perhaps you're confusing me and "toyg"?
- Eric_WVGG 3y ago
  This is turning into a silly argument… but anyway there's a blogger who has been tracking the number of binaries written in the various languages (and appkit vs catalyst vs swiftui etc.) for years. Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago). https://blog.timac.org/2023/1128-state-of-appkit-catalyst-swift-swiftui-mac/ https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
  - jshier 3y ago
    At this point you can't separate Swift from the rest of the system so cleanly. Since it's now included with the OS directly and linked to from many system libraries, including parts of Foundation which have been directly rewritten in Swift while maintaining ABI compatibility with Obj-C callers, virtually everything on the system that uses Apple's frameworks uses Swift to some degree.
rewgs 3y ago
> Swift is for the new rubes, bootcamp graduates and so on. That was a bit rude and unnecessary.
throwaway2037 3y ago
One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?
- jimbokun 3y ago
  > The developer productivity in Swift must be 10x compared to Objective C. Why do you say that? Do you have experience backing up that estimate?
  - throwaway2037 3y ago
    When I switch between C or C++ and a (non-deterministic) VM-based language like Java or C#, it feels like 10x. The IDEs are way more advanced, including (for me) the #1 all-important: debugging. For me (a mere mortal, average programmer), the fact that null pointer exceptions are clear in Java/C# is a huge gain compared "core dump" in C or C++. Going further, I am sure many would say the same kind of productivity speed-up for C or C++ to Python or Ruby.
    - Gibbon1 3y ago
      I have a bit of code I use for ARM Cortex devices where I can trap bus errors. Most of the time I can recover the program counter where that happened. And use addr2line to get the file and line number. I've heard game developers talk about doing that sort of thing as well. I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043' In C++ I'm dubious you couldn't throw an exception instead of dumping. [1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.

by toyg 3y ago

jshier 3y ago

They're literally rewriting in Swift right now. Foundation is being rewritten entirely in Swift. All new code is in Swift. All new frameworks are Swift-only. They're using Swift from low level firmware on the Secure Enclave to apps. This is already real.

deleted 3y ago
[deleted]
sandyarmstrong 3y ago
Yup, exactly. Swift was specifically designed to replace Objective-C and C++ throughout Apple codebases (see https://www.youtube.com/watch?v=ZQc9-seU-5k https://www.youtube.com/watch?v=ZQc9-seU-5k). C# is a totally different story.
- throwaway2037 3y ago
  > C# is a totally different story. Interesting. Can you share more details?
  - sandyarmstrong 3y ago
    Disclaimer: I work for Microsoft, though I wasn't there during the early days of .NET or Windows Longhorn. C# was created as a Java competitor. Although it had great C interoperability, the underlying .NET Framework was still a VM-based runtime with a garbage collector and all the disadvantages that brings. You can probably find various articles (https://longhorn.ms/the-reset/ https://longhorn.ms/the-reset/ is one) discussing attempts to adopt C#/.NET code for Windows Longhorn, which ultimately had to be walked back completely. .NET wasn't purpose-built for writing OS components or working deep inside existing Windows code. Apple learned from this and other examples. The Swift team actively works with teams at Apple deep in native code to make sure they can handle their use cases without performance penalties, and with minimal ergonomic issues. The difference is really about what the stated goals of the language were/are.
    - throwaway2037 3y ago
      Thank you to share. My guess: In the year 2000, it was impossible with current desktop computing power to use C# for OS internals. In 2024, it is a different story.
toyg 3y ago
That's what MS said as well, when they were pushing C#. All Windows will be using safe code! Still waiting... Another example is Mozilla and Rust - hell, I wouldn't be surprised if there was still Netscape code somewhere in the bowels of FF/TB! Sure, Apple cares less about backward compatibility, but still, it's unlikely Objective-C is going anywhere, under the hood.
lapcat 3y ago
> Foundation is being rewritten entirely in Swift. That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple). > All new code is in Swift. False. > All new frameworks are Swift-only. False.
- jshier 3y ago
  > That's a mult-year project in its very early stages, yet we're already almost 10 years into Swift (more than 10 years of Swift internally to Apple). It has already shipped, replacing parts of Foundation in the 2023 OS versions. It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong. My other points were a bit hyperbolic. Feel free the replace "all" with "the vast majority of". Apple obviously still writes Obj-C in their existing Obj-C frameworks, and doesn't arbitrarily rewrite into Swift, but their internal barriers to use Swift are now almost entirely gone. And I can't think of an entirely new framework that wasn't Swift-only recently.
  - lapcat 3y ago
    > It continues to grow, and it's a rewrite, so it certainly proves your assertion wrong. Which assertion was wrong? I was paraphrasing from the project page itself: "It is in its early stages with many features still to be implemented." https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation
    - jshier 3y ago
      > Which assertion was wrong? Your original assertion that Apple wasn't rewriting anything.
      - lapcat 3y ago
        > Your original assertion that Apple wasn't rewriting anything. I have no idea what you're talking about. I made no such assertion. Perhaps you're confusing me and "toyg"?
Eric_WVGG 3y ago
This is turning into a silly argument… but anyway there's a blogger who has been tracking the number of binaries written in the various languages (and appkit vs catalyst vs swiftui etc.) for years. Sonoma is 13% Swift (up from 11% in Ventura), 53% Obj-C (down from 55% in Ventura). The priority actually appears to be eating away from the C/C++ parts of the codebase (currently 33%, down from 42% just two releases ago). https://blog.timac.org/2023/1128-state-of-appkit-catalyst-swift-swiftui-mac/ https://blog.timac.org/2023/1128-state-of-appkit-catalyst-sw...
- jshier 3y ago
  At this point you can't separate Swift from the rest of the system so cleanly. Since it's now included with the OS directly and linked to from many system libraries, including parts of Foundation which have been directly rewritten in Swift while maintaining ABI compatibility with Obj-C callers, virtually everything on the system that uses Apple's frameworks uses Swift to some degree.

rewgs 3y ago

> Swift is for the new rubes, bootcamp graduates and so on. That was a bit rude and unnecessary.

throwaway2037 3y ago

One of the most complex apps that Microsoft produces is Visual Studio. It is currently a hybrid of C++ and C#. I suppose that almost all new features are written in C# where possible. Why won't Apply follow the same path? The developer productivity in Swift must be 10x compared to Objective C. To be clear: I write this post as someone who has infinite love for optimization of native code. However, in many situtations, it is simply more "dev efficient" to write code in a managed (VM) langauge. Thoughts?

jimbokun 3y ago
> The developer productivity in Swift must be 10x compared to Objective C. Why do you say that? Do you have experience backing up that estimate?
- throwaway2037 3y ago
  When I switch between C or C++ and a (non-deterministic) VM-based language like Java or C#, it feels like 10x. The IDEs are way more advanced, including (for me) the #1 all-important: debugging. For me (a mere mortal, average programmer), the fact that null pointer exceptions are clear in Java/C# is a huge gain compared "core dump" in C or C++. Going further, I am sure many would say the same kind of productivity speed-up for C or C++ to Python or Ruby.
  - Gibbon1 3y ago
    I have a bit of code I use for ARM Cortex devices where I can trap bus errors. Most of the time I can recover the program counter where that happened. And use addr2line to get the file and line number. I've heard game developers talk about doing that sort of thing as well. I would think if the C/C++ developers didn't have their head up their **[1] that could be a standard out of the box feature. There isn't any reason a program couldn't spit to stderr, 'seg_fault: file boots.c, line 1043' In C++ I'm dubious you couldn't throw an exception instead of dumping. [1] Got rid of frame pointers because they were sure that would make their dog slow C++ compilers run faster. Voice over. But it didn't make them faster. It made programs impossible to profile.