6 ms·

> I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly tar

> I hope Swift can eventually become more of a general purpose language, as its actually pretty nice and they're introducing features like this that clearly targets server-side programming. I hope for this too. I did a personal project in Swift on Linux and found that I loved the language. However, I was greatly frustrated by the lack of libraries. For Swift to reach the mainstream, IMHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I would vote for that even ahead of adding new features to the language.

xvilka 5y ago
I hope not, at least until they solve it being Apple-only. Of course, there's some support for other platforms but it's pretty bad. At this point it's better to invest time and money to the Rust ecosystem.
- ecs78 5y ago
  I think the language and runtime are evolving too fast for good support of other platforms outside of NIO based apps running in a Docker container. This should change once Swift has all the features originally planned for it. They are getting close, but there are several areas that need work. The biggest is an ownership system. But there is also variadic generics, extensions to the pattern matching system, c++ bridging, completing some missing concurrency features, SPM features, and lots of optimizations. Cross platform support is mostly for early community building right now. Much of it funded by Apple directly. Maybe around Swift 7 or 8 it will be better suited for other platforms.
DaiPlusPlus 5y ago
> MHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I suspect Apple is trying to do this for straightforward reasons like wanting to remain relevant and foster community growth as to retain credibility… while also subtly trying to not encourage the use of Swift as a language for any other GUI framework/platform than Cocoa + macOS. Obviously I don’t have any evidence to support my fantasy speculation (well, X11 for macOS is dead) - but consider how Apple is so very protective of their UX moat (and PWAs be damned). It’s not in Apple’s interests to facilitate and support any kind of true cross-platform UI framework: remember how Java AWT/Swing apps were like on OS X? The majority of dispassionate (I.e. not Panic Inc) devs are never going to optimise a cross-platform UI for macOS because the whole point of using an xplat UI is so you don’t need to spend time on platform-specific code. Those two reasons combine form a vicious-cycle negative feedback loop that devalues their platform. But with the web finally becoming the true, real, cross-platform that Microsoft was then-irrationally terrified of 25 years ago, I don’t know what Apple’s strategy is to remain the best provider of the best UX when everyone is going to be using Chromium in some form. And if Apple keeps pushing their own native apps devs to their hostile App Store while everyone else moves to the web, then the value-prop of an Apple computer looks bad compared to a Chromebook which is essentially just-as-locked-down and just-as-capable, just without iOS integration and a modest selection of (albeit) high-quality boutique Mac App Store apps. ———— On a related note: Apple does not have long-term support commitments as a matter of policy - which means enterprise/slow-moving/blue-chips won’t be interested in using Swift at all (compared to ISO-backed C++, Oracle’s Java, or MS’ .NET). Apple is going to have to maintain Swift’s support for Win32 and *nix in the long-run if they need to build their credibility and win-over large programming projects - but it’s just so against their corporate culture. It reminds me of their middling support for Safari for Windows. I know Apple gets Win32 and nix support for Swift “for free” by piggybacking off Clang+LLVM, but that’s basically the same as making Swift more like Java (“xplat for free”) but that’s just the bare-minimum they need to do: without Apple actively investing significantly in the developer experience for non-Apple platforms it just isn’t going to take-off. And they can’t do that for fear that a critical-mass of hackers will port Cocoa to Win32. Swift is basically analogue to Google’s Dart+Flutter but it wants to be like Go.
- ternaryoperator 5y ago
  My understanding (and I invite correction if I'm mistaken) is that the Swift Foundation was created to address the principal concerns you've articulated. But ports have been slow: Linux works but with the previously mentioned lack of libraries, and there is a threadbare port to Windows which barely runs. The app I was working on was CLI-based that generated a log; and even for that non-UI use case, basic libraries were effectively missing. It's a shame because it's truly an elegant language.
  - b3morales 5y ago
    It's made quite clear every summer that Apple has a stranglehold on the language steering committee. When a new language feature that just so happen to enable a closed-source Apple framework drops out of the blue and then goes through a retroactive pseudo-open review. Frankly, this distributed actors thing is more of the same -- it's something that someone at Apple thinks is important, so, despite it being just a library, it gets active support from the compiler and OS teams. There's absolutely no way that an outsider could have gotten anywhere proposing anything like this. I like Apple's platforms and enjoy working with the language as well, but the openness is rather a charade.
    - ecs78 5y ago
      Distributed actors don’t actually have compiler support. They use a standalone code generator much like GRPC. The plan is to call the generator automatically during a build process using upcoming SPM plugin support. EDIT: It looks like there is a plan to remove the SPM plugin and make it a first class feature. This work just started and is going through a normal evolution process.
      - b3morales 5y ago
        > Distributed actors don’t actually have compiler support. I said from the compiler and OS teams -- there are at least two compiler engineers listed on the proposal. But this is insupportable nonsense anyways: `distributed` is a brand new keyword, there are new rules about how inits work, magic property behavior... I haven't followed the proposal carefully, but there are also new toolchains being generated to enable the feature.

xvilka 5y ago

I hope not, at least until they solve it being Apple-only. Of course, there's some support for other platforms but it's pretty bad. At this point it's better to invest time and money to the Rust ecosystem.

ecs78 5y ago
I think the language and runtime are evolving too fast for good support of other platforms outside of NIO based apps running in a Docker container. This should change once Swift has all the features originally planned for it. They are getting close, but there are several areas that need work. The biggest is an ownership system. But there is also variadic generics, extensions to the pattern matching system, c++ bridging, completing some missing concurrency features, SPM features, and lots of optimizations. Cross platform support is mostly for early community building right now. Much of it funded by Apple directly. Maybe around Swift 7 or 8 it will be better suited for other platforms.

DaiPlusPlus 5y ago

> MHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I suspect Apple is trying to do this for straightforward reasons like wanting to remain relevant and foster community growth as to retain credibility… while also subtly trying to not encourage the use of Swift as a language for any other GUI framework/platform than Cocoa + macOS. Obviously I don’t have any evidence to support my fantasy speculation (well, X11 for macOS is dead) - but consider how Apple is so very protective of their UX moat (and PWAs be damned). It’s not in Apple’s interests to facilitate and support any kind of true cross-platform UI framework: remember how Java AWT/Swing apps were like on OS X? The majority of dispassionate (I.e. not Panic Inc) devs are never going to optimise a cross-platform UI for macOS because the whole point of using an xplat UI is so you don’t need to spend time on platform-specific code. Those two reasons combine form a vicious-cycle negative feedback loop that devalues their platform. But with the web finally becoming the true, real, cross-platform that Microsoft was then-irrationally terrified of 25 years ago, I don’t know what Apple’s strategy is to remain the best provider of the best UX when everyone is going to be using Chromium in some form. And if Apple keeps pushing their own native apps devs to their hostile App Store while everyone else moves to the web, then the value-prop of an Apple computer looks bad compared to a Chromebook which is essentially just-as-locked-down and just-as-capable, just without iOS integration and a modest selection of (albeit) high-quality boutique Mac App Store apps. ———— On a related note: Apple does not have long-term support commitments as a matter of policy - which means enterprise/slow-moving/blue-chips won’t be interested in using Swift at all (compared to ISO-backed C++, Oracle’s Java, or MS’ .NET). Apple is going to have to maintain Swift’s support for Win32 and *nix in the long-run if they need to build their credibility and win-over large programming projects - but it’s just so against their corporate culture. It reminds me of their middling support for Safari for Windows. I know Apple gets Win32 and nix support for Swift “for free” by piggybacking off Clang+LLVM, but that’s basically the same as making Swift more like Java (“xplat for free”) but that’s just the bare-minimum they need to do: without Apple actively investing significantly in the developer experience for non-Apple platforms it just isn’t going to take-off. And they can’t do that for fear that a critical-mass of hackers will port Cocoa to Win32. Swift is basically analogue to Google’s Dart+Flutter but it wants to be like Go.

ternaryoperator 5y ago
My understanding (and I invite correction if I'm mistaken) is that the Swift Foundation was created to address the principal concerns you've articulated. But ports have been slow: Linux works but with the previously mentioned lack of libraries, and there is a threadbare port to Windows which barely runs. The app I was working on was CLI-based that generated a log; and even for that non-UI use case, basic libraries were effectively missing. It's a shame because it's truly an elegant language.
- b3morales 5y ago
  It's made quite clear every summer that Apple has a stranglehold on the language steering committee. When a new language feature that just so happen to enable a closed-source Apple framework drops out of the blue and then goes through a retroactive pseudo-open review. Frankly, this distributed actors thing is more of the same -- it's something that someone at Apple thinks is important, so, despite it being just a library, it gets active support from the compiler and OS teams. There's absolutely no way that an outsider could have gotten anywhere proposing anything like this. I like Apple's platforms and enjoy working with the language as well, but the openness is rather a charade.
  - ecs78 5y ago
    Distributed actors don’t actually have compiler support. They use a standalone code generator much like GRPC. The plan is to call the generator automatically during a build process using upcoming SPM plugin support. EDIT: It looks like there is a plan to remove the SPM plugin and make it a first class feature. This work just started and is going through a normal evolution process.
    - b3morales 5y ago
      > Distributed actors don’t actually have compiler support. I said from the compiler and OS teams -- there are at least two compiler engineers listed on the proposal. But this is insupportable nonsense anyways: `distributed` is a brand new keyword, there are new rules about how inits work, magic property behavior... I haven't followed the proposal carefully, but there are also new toolchains being generated to enable the feature.