8 ms·

Swift 6 is a major leap forward for cross-platform batteries-including development IMHO. Foundation is the big win here, because it provides so much out of the

by jph 2y ago

Swift 6 is a major leap forward for cross-platform batteries-including development IMHO. Foundation is the big win here, because it provides so much out of the box. Swift 6 is the first version with enough low-level improvements and cross-platform capabilities to make me curious if the Swift team is trying to aim for long-term replacing C, C++, Rust, Zig, etc.

refulgentis 2y ago
Been using Swift since the pre-release announcement that it existed. O'Leary's Law of Swift Comments on HN, much like Betteridge's Law of Headlines, says the answer to Swift speculation on HN is always no. If there is any global aim, it is to migrate internal teams still working in ObjC/C++ to Swift. If this sounds close-minded, it's worth talking with an iOS developer 1:1 and get info on the day-to-day experience of SwiftUI 5 years in, and concurrency/actors 3 years in. They have a lot of fires to fight to keep the house standing.
- favorited 2y ago
  > Apple is not trying to potentially attempt to aim for maybe replacing every other programming language with Swift Apple's stated goal is to make Swift a viable language up and down the technology stack, which goes way beyond Objective-C. They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. IIRC they even referred to it as a C++ successor language at WWDC this year. I agree that they're not trying to "replacing every other programming language," but they're investing in it becoming a viable language choice in most environments.
  - refulgentis 2y ago
    > they even referred to it as a C++ successor language Nice! I'd gently warn against parsing that too closely: having been in the community and the weeds starting in 2014(!). ex. the cross platform Foundation was announced and open sourced in 2016. I'm sure a lot of things were upgraded or more consistent and its better etc., but it's a painful to remember what was expected + communicated at the time, and how much later it is.
  - tcmart14 2y ago
    Which I think that makes sense for them to want it to be viable all over the stack. It also directly benefits them also. I am assuming a lot of the motivation for embedded swift is being able to use it in their own stacks. I think even the presentation for WWDC gave examples of it being used in some pieces of hardware like on the AppleTV?
  - rudedogg 2y ago
    > They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. I don’t think Swift has a place in these niches FWIW. Writing low-level Swift code is very verbose and unnatural. Personally I just don’t think it’s practical to have a single language excel across the stack.
  - newaccount74 2y ago
    I think the goal of Swift on the server, or embedded Swift, is mainly to offer Mac and iOS developers a way to write everything in the same language. Right now, my Mac app depends on a few simple web services that are written in a different language. It would be neat if those services could be written in Swift, so that I could just use the language I already know instead of relearning how to do decode JSON in Python/Ruby/PHP. Swift on the server doesn't have to become widely used. As long as there is a simple way to write basic web services, it is useful.
    - pzo 2y ago
      > It would be neat if those services could be written in Swift, so that I could just use the language I already know Then somebody else would have to now learn Swift even thought they write in different language like: Android Developers (Kotlin/Java), React Native devs (JS/TS ), Windows Devs, Linux Devs etc. As long as Apple don't invest more in official cross-platform tooling Swift is not gonna be mainstream (even though I like Swift). They have to bless other competing platforms.
      - newaccount74 2y ago
        I was more thinking of smaller teams or individual developers that are Apple only. If you have a bigger team, then it doesn't matter as much, because you have different people who do the iOS app, people who do the website, people who do the back end etc. Swift on the server doesn't have to go mainstream to be useful. If you just need some basic web service that syncs highscores or verifies in-app purchases then it would be neat if you could write that in the same language as the app itself.
  - myko 2y ago
    John McCall (Swift team) gave a talk on Swift replacing C++ earlier this year: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw Selfishly I wish mixed C targets were a priority before C++ but I get why this was more important to them
  - mpweiher 2y ago
    Huh? Objective-C was in the kernel.
    - lukeh 2y ago
      In NEXTSTEP, yes, but not macOS.
      - mpweiher 2y ago
        And they regretted the decision not to do it in macOS.
    - MBCook 2y ago
      Was it? Objective-C requires a runtime. I thought the kernel was always C/C++.
      - favorited 2y ago
        There is code in the kernel to enable treating types like `os_log_t` and Clang blocks as Objective-C objects higher up the stack, but the XNU kernel itself is almost entirely C and C++.
        mpweiher 2y ago
        Yeah, on macOS. On NeXTStep / OPENSTEP kernel drivers could be and were written in Objective-C. https://www.nextcomputers.org/files/manuals/nd/OperatingSystem/Part3_DriverKit/Reference/Classes/IntroDriverKitClasses.htmld/index.html https://www.nextcomputers.org/files/manuals/nd/OperatingSyst...
      - KerrAvon 2y ago
        NeXTstep 3.3 supported Objective-C drivers in the kernel. Mac OS X's IOKit changed them to use a (poorly defined/maintained subset of) C++.
        MBCook 2y ago
  - saagarjha 2y ago
    Apple says a lot of things at WWDC. Not all of them are entirely honest.
    - MBCook 2y ago
      Do you have any evidence they’re not targeting it as their main everywhere language? It’s already been used in their libraries, their OSes, and even firmware on embedded processors.
      - saagarjha 2y ago
        I think this conversation has a lot of parallels to their public views on SwiftUI. Are they working on it? Yes. Will it maybe end up being what they consolidate around sometime in the future? Maybe. Does that mean you should believe them when they say it’s the biggest thing you should invest in right now? No.
        MBCook 2y ago
        They’re pretty clear on both. UIKit, AppKit, and Objective-C(++) aren’t getting new features except in rare cases. This is the way forward. And they’re dogfooding it. Even in some of their embedded processors.
    - lapcat 2y ago
      https://live.arstechnica.com/apples-wwdc-2014-keynote/images/IMG_0018.JPG https://live.arstechnica.com/apples-wwdc-2014-keynote/images...
Verdex 2y ago
I feel like the whole issue with c++ is that in order to create a language able to do everything you more or less have to include a feature set that is 'unharmonious' to say the least. To me it kind of feels like swift's place here is going to replace the subset of c++ that apple is mostly interested in. But not necessarily the c++ that they aren't and then likely not the c++ that rust et al are able to replace (although I guess we'll see what they have in mind as time goes by). I suspect they'll be disappointed if they try to replace c++ in totality. As the end result will likely not be particularly habitable.
- MBCook 2y ago
  > I suspect they'll be disappointed if they try to replace c++ in totality. Why is that? That is their aim, I think they’ve made it clear. They’re writing all-ish new code in Swift (not always practical in existing code) from what I understand. They’re already using it for the code that runs in places like the Secure Enclave or other embedded processors. Can it replace C++ 100% everywhere today? Probably not. I don’t know enough to know why. But that absolutely appears to be the goal.
multimoon 2y ago
The most batteries included multiplatform language right now is _by far_ Kotlin and nothing else is remotely close. The ecosystem is amazing, the language itself is awesome and follows sane rules, you can chose between native code, JVM, WASM, or JS-IR, or all as backends to compile to (for the exact same code) depending on your use case. Compose Multiplatform is also wonderful and by far my favorite UI library now and I’ve shipped a fair bit of code with it. It’s a single UI library that I can share my UI across every platform (including iOS and android), and even seamlessly interop with native widgets on platforms like iOS if I need to, like the camera viewfinder for example. Kotlin’s real strength is the compilers ability to target as many different backends as you want and cross compile into any platform you want. I have an app in production that save for about three lines of swift that declares the view controller for iOS specifically, shares its entire codebase all in kotlin between Android, iOS, Mac, Linux, and Windows. I could add a line to the build file and add web as a target and turn it into a web app.
- jb1991 2y ago
  The comment you are replying to was focusing more on the low-level features of Swift for systems programming (hence comparing it to systems languages). Kotlin is cool but it is not a system programming language and the native code compilation from Kotlin is not aimed to be.
  - iainmerrick 2y ago
    That earlier comment didn’t actually mention “systems” at all (although it does include “low-level”). I feel like “systems programming” is getting increasingly ill-defined these days, anyway. If Kotlin and Java aren’t allowed, how about Go? Are you ruling out all languages with garbage collection?
    - refulgentis 2y ago
      You're right to note systems programming doesn't involve GC usually
    - MarcusE1W 2y ago
WhitneyLand 2y ago
It’s too slow. I can’t stand waiting for builds on what I would call a medium sized project. I haven’t given 6.0 a full effort yet, but a couple test compiles without any tuning showed only incremental improvements.
bsaul 2y ago
Any idea if compiling for android ( at least the data part) will now be supported ?
- pjmlp 2y ago
  If if it does, it isn't like using NDK and going through JNI for anything useful outside game development is that great experiece. People keep doing that, because I guess they hatred for Java and Kotlin is higher than the pain of using NDK.
- marcprux 2y ago
  I recently wrote about using a native Swift toolchain for Android: https://skip.tools/blog/native-swift-on-android-1/ https://skip.tools/blog/native-swift-on-android-1/
pjmlp 2y ago
Long-term replacement of C, C++, and Objective-C on Apple's ecosystem has been on Swift documentation as mission statement since day one. I don't get how people still get surprised by this.

by jph 2y ago

refulgentis 2y ago

Been using Swift since the pre-release announcement that it existed. O'Leary's Law of Swift Comments on HN, much like Betteridge's Law of Headlines, says the answer to Swift speculation on HN is always no. If there is any global aim, it is to migrate internal teams still working in ObjC/C++ to Swift. If this sounds close-minded, it's worth talking with an iOS developer 1:1 and get info on the day-to-day experience of SwiftUI 5 years in, and concurrency/actors 3 years in. They have a lot of fires to fight to keep the house standing.

favorited 2y ago
> Apple is not trying to potentially attempt to aim for maybe replacing every other programming language with Swift Apple's stated goal is to make Swift a viable language up and down the technology stack, which goes way beyond Objective-C. They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. IIRC they even referred to it as a C++ successor language at WWDC this year. I agree that they're not trying to "replacing every other programming language," but they're investing in it becoming a viable language choice in most environments.
- refulgentis 2y ago
  > they even referred to it as a C++ successor language Nice! I'd gently warn against parsing that too closely: having been in the community and the weeds starting in 2014(!). ex. the cross platform Foundation was announced and open sourced in 2016. I'm sure a lot of things were upgraded or more consistent and its better etc., but it's a painful to remember what was expected + communicated at the time, and how much later it is.
- tcmart14 2y ago
  Which I think that makes sense for them to want it to be viable all over the stack. It also directly benefits them also. I am assuming a lot of the motivation for embedded swift is being able to use it in their own stacks. I think even the presentation for WWDC gave examples of it being used in some pieces of hardware like on the AppleTV?
- rudedogg 2y ago
  > They are actively working on making Swift viable in baremetal environments, firmware, drivers, etc. I don’t think Swift has a place in these niches FWIW. Writing low-level Swift code is very verbose and unnatural. Personally I just don’t think it’s practical to have a single language excel across the stack.
- newaccount74 2y ago
  I think the goal of Swift on the server, or embedded Swift, is mainly to offer Mac and iOS developers a way to write everything in the same language. Right now, my Mac app depends on a few simple web services that are written in a different language. It would be neat if those services could be written in Swift, so that I could just use the language I already know instead of relearning how to do decode JSON in Python/Ruby/PHP. Swift on the server doesn't have to become widely used. As long as there is a simple way to write basic web services, it is useful.
  - pzo 2y ago
    > It would be neat if those services could be written in Swift, so that I could just use the language I already know Then somebody else would have to now learn Swift even thought they write in different language like: Android Developers (Kotlin/Java), React Native devs (JS/TS ), Windows Devs, Linux Devs etc. As long as Apple don't invest more in official cross-platform tooling Swift is not gonna be mainstream (even though I like Swift). They have to bless other competing platforms.
    - newaccount74 2y ago
      I was more thinking of smaller teams or individual developers that are Apple only. If you have a bigger team, then it doesn't matter as much, because you have different people who do the iOS app, people who do the website, people who do the back end etc. Swift on the server doesn't have to go mainstream to be useful. If you just need some basic web service that syncs highscores or verifies in-app purchases then it would be neat if you could write that in the same language as the app itself.
- myko 2y ago
  John McCall (Swift team) gave a talk on Swift replacing C++ earlier this year: https://www.youtube.com/watch?v=lgivCGdmFrw https://www.youtube.com/watch?v=lgivCGdmFrw Selfishly I wish mixed C targets were a priority before C++ but I get why this was more important to them
- mpweiher 2y ago
  Huh? Objective-C was in the kernel.
  - lukeh 2y ago
    In NEXTSTEP, yes, but not macOS.
    - mpweiher 2y ago
      And they regretted the decision not to do it in macOS.
  - MBCook 2y ago
    Was it? Objective-C requires a runtime. I thought the kernel was always C/C++.
    - favorited 2y ago
      There is code in the kernel to enable treating types like `os_log_t` and Clang blocks as Objective-C objects higher up the stack, but the XNU kernel itself is almost entirely C and C++.
      - mpweiher 2y ago
        Yeah, on macOS. On NeXTStep / OPENSTEP kernel drivers could be and were written in Objective-C. https://www.nextcomputers.org/files/manuals/nd/OperatingSystem/Part3_DriverKit/Reference/Classes/IntroDriverKitClasses.htmld/index.html https://www.nextcomputers.org/files/manuals/nd/OperatingSyst...
    - KerrAvon 2y ago
      NeXTstep 3.3 supported Objective-C drivers in the kernel. Mac OS X's IOKit changed them to use a (poorly defined/maintained subset of) C++.
      - MBCook 2y ago
- saagarjha 2y ago
  Apple says a lot of things at WWDC. Not all of them are entirely honest.
  - MBCook 2y ago
    Do you have any evidence they’re not targeting it as their main everywhere language? It’s already been used in their libraries, their OSes, and even firmware on embedded processors.
    - saagarjha 2y ago
      I think this conversation has a lot of parallels to their public views on SwiftUI. Are they working on it? Yes. Will it maybe end up being what they consolidate around sometime in the future? Maybe. Does that mean you should believe them when they say it’s the biggest thing you should invest in right now? No.
      - MBCook 2y ago
        They’re pretty clear on both. UIKit, AppKit, and Objective-C(++) aren’t getting new features except in rare cases. This is the way forward. And they’re dogfooding it. Even in some of their embedded processors.
  - lapcat 2y ago
    https://live.arstechnica.com/apples-wwdc-2014-keynote/images/IMG_0018.JPG https://live.arstechnica.com/apples-wwdc-2014-keynote/images...

Verdex 2y ago

I feel like the whole issue with c++ is that in order to create a language able to do everything you more or less have to include a feature set that is 'unharmonious' to say the least. To me it kind of feels like swift's place here is going to replace the subset of c++ that apple is mostly interested in. But not necessarily the c++ that they aren't and then likely not the c++ that rust et al are able to replace (although I guess we'll see what they have in mind as time goes by). I suspect they'll be disappointed if they try to replace c++ in totality. As the end result will likely not be particularly habitable.

MBCook 2y ago
> I suspect they'll be disappointed if they try to replace c++ in totality. Why is that? That is their aim, I think they’ve made it clear. They’re writing all-ish new code in Swift (not always practical in existing code) from what I understand. They’re already using it for the code that runs in places like the Secure Enclave or other embedded processors. Can it replace C++ 100% everywhere today? Probably not. I don’t know enough to know why. But that absolutely appears to be the goal.

multimoon 2y ago

The most batteries included multiplatform language right now is _by far_ Kotlin and nothing else is remotely close. The ecosystem is amazing, the language itself is awesome and follows sane rules, you can chose between native code, JVM, WASM, or JS-IR, or all as backends to compile to (for the exact same code) depending on your use case. Compose Multiplatform is also wonderful and by far my favorite UI library now and I’ve shipped a fair bit of code with it. It’s a single UI library that I can share my UI across every platform (including iOS and android), and even seamlessly interop with native widgets on platforms like iOS if I need to, like the camera viewfinder for example. Kotlin’s real strength is the compilers ability to target as many different backends as you want and cross compile into any platform you want. I have an app in production that save for about three lines of swift that declares the view controller for iOS specifically, shares its entire codebase all in kotlin between Android, iOS, Mac, Linux, and Windows. I could add a line to the build file and add web as a target and turn it into a web app.

jb1991 2y ago
The comment you are replying to was focusing more on the low-level features of Swift for systems programming (hence comparing it to systems languages). Kotlin is cool but it is not a system programming language and the native code compilation from Kotlin is not aimed to be.
- iainmerrick 2y ago
  That earlier comment didn’t actually mention “systems” at all (although it does include “low-level”). I feel like “systems programming” is getting increasingly ill-defined these days, anyway. If Kotlin and Java aren’t allowed, how about Go? Are you ruling out all languages with garbage collection?
  - refulgentis 2y ago
    You're right to note systems programming doesn't involve GC usually
  - MarcusE1W 2y ago

WhitneyLand 2y ago

It’s too slow. I can’t stand waiting for builds on what I would call a medium sized project. I haven’t given 6.0 a full effort yet, but a couple test compiles without any tuning showed only incremental improvements.

bsaul 2y ago

Any idea if compiling for android ( at least the data part) will now be supported ?

pjmlp 2y ago
If if it does, it isn't like using NDK and going through JNI for anything useful outside game development is that great experiece. People keep doing that, because I guess they hatred for Java and Kotlin is higher than the pain of using NDK.
marcprux 2y ago
I recently wrote about using a native Swift toolchain for Android: https://skip.tools/blog/native-swift-on-android-1/ https://skip.tools/blog/native-swift-on-android-1/

pjmlp 2y ago

Long-term replacement of C, C++, and Objective-C on Apple's ecosystem has been on Swift documentation as mission statement since day one. I don't get how people still get surprised by this.