6 ms·

Swift is slowly evolving into a formidable competitor to C++, and Rust. SwiftNIO, Swift on Windows and now this multiplatform System library, Swift is truly on

Swift is slowly evolving into a formidable competitor to C++, and Rust. SwiftNIO, Swift on Windows and now this multiplatform System library, Swift is truly on its way to become a mainstream systems language. Exciting Tim times indeed!

pjmlp 6y ago
On Apple platforms yes, on the other ones still needs to learn to walk, before it can fight.
- sedatk 6y ago
  OP said systems language, and what’s Swift lacking there on other platforms?
  - zamalek 6y ago
    Sane APIs (with exception of course, SwiftUI looked beyond Apple's ecosystem for inspiration). If you've been putting up with the [lack of] iOS API ergonomics for years, by all means, Swift will look like a substantial step forward. If you're used to thoughtful and quality APIs, the marriage between Swift and NSDrunkApiDesign is an incredibly unattractive proposition. I really just refuse to tolerate those APIs on platforms (.Net) and languages (Rust stdlib) where more sensible APIs are available. If there were an alternative stdlib for Swift that lacked/wrapped the iOS quirks, I'd probably be all for it.
    - saagarjha 6y ago
      Swift ships with an extremely polished, well designed standard library out-of-the-box. You can use it with a simple "import Swift"…wait, you don't even need to do that, because it's available by default.
      - zamalek 6y ago
        Why do I then see NSGarbage all over the place in Swift code? Swift is a language facade over Objective C.
        saagarjha 6y ago
        Because Swift allows interoperatability with Objective-C frameworks, such as the ones that ship with Apple's platforms. It's easy to see that Swift is not a language façade over Objective-C because you can write a type that cannot be represented in Objective-C almost trivially.
        zamalek 6y ago
        But you still have to use the awful ObjectiveC idioms. That's the problem. I did not refer to the limited Swift wrappers, I in-fact explicitly excluded it.
        saagarjha 6y ago
        You have to use Objective-C idioms because Apple wrote that code in Objective-C, not Swift. If your complaint is "why can't Swift take my Objective-C code and not only provide a fairly decent interface to it, completely change the API so that it fits perfectly into Swift regardless of issues like ownership and interface design" that's just an impossible bar to set for it.
        zamalek 6y ago
        Rust has done that, with multiple platforms. .Net has done that, with multiple platforms. Dart has done that, with multiple platforms. Apple doesn't care for anything except iOS. That is why Swift won't be taken seriously on anything except iOS.
        saagarjha 6y ago
        As far as I am aware, all of those require someone to explicitly go in and create a wrapper, which is worse than what Swift gives you out of the box. So how are they better?
  - meragrin_ 6y ago
    Well, it has only been available on Windows specifically for early adopters for a few days now. I imagine it has a long ways to go to prove itself there.
  - hguant 6y ago
    Technically? Nothing, you can do many things with Swift as a systems level language, and there are some interesting aspects to it. Swift was my first introduction to the power of traits and protocols, and I'll be forever fond of it for that. However, for the project I was on, when I was working on it, Swift on Linux was a massive pain in the ass, mostly due to documentation and dependency hell. Documentation was extremely useless; the number of times I was told "oh yes there's a swift way to do that!" only to find out the 'swift' way was to wrap a Cocoa library or just drop in some Objective-C module. If I recall correctly, there was an issue with pthreads not being properly implemented at the time, relying on some hacks to get it to 'work' while they figured out a 1.0 implementation. We got it to work, eventually, but the hoops we had to jump through really pushed our team to Rust as our general purpose systems language. I'm glad they seem to have got it working, but I'm never subjecting myself to trying to get Apple's nonesense working outside of iOS or macOS again.
    - sedatk 6y ago
      So, you had problems with the exact same thing Apple set out to fix with open System library? I’d say they are on the right track then.
    - andrewjl 6y ago
      Supporting a language fully on a variety of non-Apple platforms is a massive undertaking. Even assuming for the sake of argument, unlimited funding, there's still the issue of finding the right talent, as well as expending limited managerial bandwidth for oversight & prioritization. I think the Linux support that already exists is an awesome start. But the only realistic way to see more from Apple on this is if they themselves start to deploy critical Swift web-services on their own backend infra. (I'm assuming here that they run Linux systems somewhere in their stack.) That will give them the incentive to take it to the next level. Until then it's largely left to the community to find the energy and time to do this.
      - pjmlp 6y ago
        Apparently Google, Microsoft, Oracle, IBM, Azul, Mozilla managed to do it. Apple has enough in the bank to do it as well.
  - monadic2 6y ago
    Idiomatic libraries for a cross-platform UI, same as every language, system or non. If you're not targeting an apple UI the choice of swift is entirely confusing because it has even less of an ecosystem to build off of than where it's popular.
mhh__ 6y ago
What's the USP for swift? To my eye it looks too far away from C++ to catch on without a big selling point, but also doesn't have central thesis as it's core like Rust.
- FlyingSnake 6y ago
  Swift can be a great alternative to C++, and it’s learning curve is smaller than Rust. Of course it had a long way to go, but nevertheless it is a interesting language.
rektide 6y ago
Harsh take, but IMO you are irrelevant & asleep as a language unless you have something to offer on: https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations Phrased another way, your language should be participating in the future of HTTP, which is HTTP3 aka HTTP-over-QUIC. Swift's absence here indicates, to me, that Swift does not take itself seriously as a tool for delivering server side systems. IBM dropping swift was another pretty strong indicator to me. They really tried, they wanted to believe. But this seems like an insular, closed off world, however much they keep going through long lengths like this effort here to open themselves up & make themselves accessible to the rest of the world. Their attempts to build bridges haven't seemed to make people be very interested in transitting over to their parcel of land, the advantages aren't clear, choices of language just don't seem that relevant, there's some advantages but overall the day to day won't be radically different except that you'll be an outsider hanging out with a bunch of people mostly entirely doing iOS. I'd be happy to be wrong, seems decent enough, maybe there's some real differentiation that truly improves life, but it also seems like it's a C# type situation, where it exists & is developed only to keep the natives in spirits & from getting restless. I want to re-iterate that I think Swift seems pretty ok. More than not-bad. But languages just don't seem that relevant to me any more. Rust is being extra-strict, but otherwise, the feature-sets of languages doesn't seem very notable. There's some preferences & styles, some community favor that distinguishes languages, but by & large the work is not that different. I'm not sure what I would suggest to Swift to help themselves rise above, to underscore their own meaningfulness, in this kind of murky abyss-like scenario I've painted. I do think trying to win some AI champions makes sense; python seems to be unshakeable there, but that also means there's opportunity for better/different. Trying to get some web-developers web-platform folk on your side is usually a pretty big win, but not easy, & very factionalized already. It's weird days for languages.
- floatboth 6y ago
  > your language should be participating in the future of HTTP Nah. It's fine to leave any networking to external libraries.
  - rektide 6y ago
k__ 6y ago
"Swift is slowly evolving into a formidable competitor to ... Rust" "Swift uses Automatic Reference Counting (ARC) to manage memory."
- pjmlp 6y ago
  Just like many Rust code bases that are full of Rc<RefCell<>>, which don't get optimised away by the compiler.
  - pornel 6y ago
    Even that poor case in Rust is already better than what Swift can do, because Swift's refcounting has to be atomic. Swift is too dynamic to prove objects don't escape threads, so it can't optimize that cost away. Rust's Rc/Arc can still selectively use borrowing, which guarantees the level of efficiency that in Swift may or may not happen depending on the optimizer. A borrowed Arc can often stay borrowed across many non-inlined method calls, which you're unlikely to get in Swift.
    - k__ 6y ago
      I really have to learn more about Rust.
    - pjmlp 6y ago
      That assuming that the developer hasn't plagued the code with unnecessary clone() in an attempt to make everything finally compile.
whatever_dude 6y ago
Only that Apple's track record for supporting anything long term, cross platform, "open", is non-existent. At this point I don't even care about how good their language is. Apple has a very, very long way to go before I can trust them on anything of that magnitude. I would instead assume they WILL pull the rug from under developers for any random reason. (And I say this as an iOS developer)
- 1propionyl 6y ago
  One counterexample that comes to mind is CUPS (the printing system). LLVM and WebKit are also extremely non-trivial open source (and cross platform) contributions. Most Linux users here likely use one or two out of three of these on a weekly basis. Many likely use all three on a weekly basis. Some use all three daily.
  - formerly_proven 6y ago
    Apple has removed most stuff that's needed for non-mac platforms from CUPS over the years, which are maintained by the Linux community separately now. WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink instead. LLVM is developed by many companies these days, including Intel, Sony and Google.
    - kayodelycaon 6y ago
      At least one command line tool in my toolbox uses webkit. (wkhtmltopdf)
    - floatboth 6y ago
      > Apple has removed most stuff that's needed for non-mac platforms from CUPS over the years Wrong. Upstream CUPS on Apple's github has support for everything, even systemd. > WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink GTK's WebView (and browsers like Epiphany aka GNOME Web) use WebKit, complete with Apple's web inspector / devtools.
nendroid 6y ago
That what they said about Go but the inclusion of a GC made it only popular among python like programmers.
- dgellow 6y ago
  And Java developers. And Ruby developers. And node developers.
  - vips7L 6y ago
    Most Java devs I know wouldn't touch go. Lack of generics, proper collection classes and having to manually iterate everything isn't very attractive to people who have these features.

pjmlp 6y ago

On Apple platforms yes, on the other ones still needs to learn to walk, before it can fight.

sedatk 6y ago
OP said systems language, and what’s Swift lacking there on other platforms?
- zamalek 6y ago
  Sane APIs (with exception of course, SwiftUI looked beyond Apple's ecosystem for inspiration). If you've been putting up with the [lack of] iOS API ergonomics for years, by all means, Swift will look like a substantial step forward. If you're used to thoughtful and quality APIs, the marriage between Swift and NSDrunkApiDesign is an incredibly unattractive proposition. I really just refuse to tolerate those APIs on platforms (.Net) and languages (Rust stdlib) where more sensible APIs are available. If there were an alternative stdlib for Swift that lacked/wrapped the iOS quirks, I'd probably be all for it.
  - saagarjha 6y ago
    Swift ships with an extremely polished, well designed standard library out-of-the-box. You can use it with a simple "import Swift"…wait, you don't even need to do that, because it's available by default.
    - zamalek 6y ago
      Why do I then see NSGarbage all over the place in Swift code? Swift is a language facade over Objective C.
      - saagarjha 6y ago
        Because Swift allows interoperatability with Objective-C frameworks, such as the ones that ship with Apple's platforms. It's easy to see that Swift is not a language façade over Objective-C because you can write a type that cannot be represented in Objective-C almost trivially.
        zamalek 6y ago
        But you still have to use the awful ObjectiveC idioms. That's the problem. I did not refer to the limited Swift wrappers, I in-fact explicitly excluded it.
        saagarjha 6y ago
        You have to use Objective-C idioms because Apple wrote that code in Objective-C, not Swift. If your complaint is "why can't Swift take my Objective-C code and not only provide a fairly decent interface to it, completely change the API so that it fits perfectly into Swift regardless of issues like ownership and interface design" that's just an impossible bar to set for it.
        zamalek 6y ago
        Rust has done that, with multiple platforms. .Net has done that, with multiple platforms. Dart has done that, with multiple platforms. Apple doesn't care for anything except iOS. That is why Swift won't be taken seriously on anything except iOS.
        saagarjha 6y ago
        As far as I am aware, all of those require someone to explicitly go in and create a wrapper, which is worse than what Swift gives you out of the box. So how are they better?
- meragrin_ 6y ago
  Well, it has only been available on Windows specifically for early adopters for a few days now. I imagine it has a long ways to go to prove itself there.
- hguant 6y ago
  Technically? Nothing, you can do many things with Swift as a systems level language, and there are some interesting aspects to it. Swift was my first introduction to the power of traits and protocols, and I'll be forever fond of it for that. However, for the project I was on, when I was working on it, Swift on Linux was a massive pain in the ass, mostly due to documentation and dependency hell. Documentation was extremely useless; the number of times I was told "oh yes there's a swift way to do that!" only to find out the 'swift' way was to wrap a Cocoa library or just drop in some Objective-C module. If I recall correctly, there was an issue with pthreads not being properly implemented at the time, relying on some hacks to get it to 'work' while they figured out a 1.0 implementation. We got it to work, eventually, but the hoops we had to jump through really pushed our team to Rust as our general purpose systems language. I'm glad they seem to have got it working, but I'm never subjecting myself to trying to get Apple's nonesense working outside of iOS or macOS again.
  - sedatk 6y ago
    So, you had problems with the exact same thing Apple set out to fix with open System library? I’d say they are on the right track then.
  - andrewjl 6y ago
    Supporting a language fully on a variety of non-Apple platforms is a massive undertaking. Even assuming for the sake of argument, unlimited funding, there's still the issue of finding the right talent, as well as expending limited managerial bandwidth for oversight & prioritization. I think the Linux support that already exists is an awesome start. But the only realistic way to see more from Apple on this is if they themselves start to deploy critical Swift web-services on their own backend infra. (I'm assuming here that they run Linux systems somewhere in their stack.) That will give them the incentive to take it to the next level. Until then it's largely left to the community to find the energy and time to do this.
    - pjmlp 6y ago
      Apparently Google, Microsoft, Oracle, IBM, Azul, Mozilla managed to do it. Apple has enough in the bank to do it as well.
- monadic2 6y ago
  Idiomatic libraries for a cross-platform UI, same as every language, system or non. If you're not targeting an apple UI the choice of swift is entirely confusing because it has even less of an ecosystem to build off of than where it's popular.

mhh__ 6y ago

What's the USP for swift? To my eye it looks too far away from C++ to catch on without a big selling point, but also doesn't have central thesis as it's core like Rust.

FlyingSnake 6y ago
Swift can be a great alternative to C++, and it’s learning curve is smaller than Rust. Of course it had a long way to go, but nevertheless it is a interesting language.

rektide 6y ago

Harsh take, but IMO you are irrelevant & asleep as a language unless you have something to offer on: https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations Phrased another way, your language should be participating in the future of HTTP, which is HTTP3 aka HTTP-over-QUIC. Swift's absence here indicates, to me, that Swift does not take itself seriously as a tool for delivering server side systems. IBM dropping swift was another pretty strong indicator to me. They really tried, they wanted to believe. But this seems like an insular, closed off world, however much they keep going through long lengths like this effort here to open themselves up & make themselves accessible to the rest of the world. Their attempts to build bridges haven't seemed to make people be very interested in transitting over to their parcel of land, the advantages aren't clear, choices of language just don't seem that relevant, there's some advantages but overall the day to day won't be radically different except that you'll be an outsider hanging out with a bunch of people mostly entirely doing iOS. I'd be happy to be wrong, seems decent enough, maybe there's some real differentiation that truly improves life, but it also seems like it's a C# type situation, where it exists & is developed only to keep the natives in spirits & from getting restless. I want to re-iterate that I think Swift seems pretty ok. More than not-bad. But languages just don't seem that relevant to me any more. Rust is being extra-strict, but otherwise, the feature-sets of languages doesn't seem very notable. There's some preferences & styles, some community favor that distinguishes languages, but by & large the work is not that different. I'm not sure what I would suggest to Swift to help themselves rise above, to underscore their own meaningfulness, in this kind of murky abyss-like scenario I've painted. I do think trying to win some AI champions makes sense; python seems to be unshakeable there, but that also means there's opportunity for better/different. Trying to get some web-developers web-platform folk on your side is usually a pretty big win, but not easy, & very factionalized already. It's weird days for languages.

floatboth 6y ago
> your language should be participating in the future of HTTP Nah. It's fine to leave any networking to external libraries.
- rektide 6y ago

k__ 6y ago

"Swift is slowly evolving into a formidable competitor to ... Rust" "Swift uses Automatic Reference Counting (ARC) to manage memory."

pjmlp 6y ago
Just like many Rust code bases that are full of Rc<RefCell<>>, which don't get optimised away by the compiler.
- pornel 6y ago
  Even that poor case in Rust is already better than what Swift can do, because Swift's refcounting has to be atomic. Swift is too dynamic to prove objects don't escape threads, so it can't optimize that cost away. Rust's Rc/Arc can still selectively use borrowing, which guarantees the level of efficiency that in Swift may or may not happen depending on the optimizer. A borrowed Arc can often stay borrowed across many non-inlined method calls, which you're unlikely to get in Swift.
  - k__ 6y ago
    I really have to learn more about Rust.
  - pjmlp 6y ago
    That assuming that the developer hasn't plagued the code with unnecessary clone() in an attempt to make everything finally compile.

whatever_dude 6y ago

Only that Apple's track record for supporting anything long term, cross platform, "open", is non-existent. At this point I don't even care about how good their language is. Apple has a very, very long way to go before I can trust them on anything of that magnitude. I would instead assume they WILL pull the rug from under developers for any random reason. (And I say this as an iOS developer)

1propionyl 6y ago
One counterexample that comes to mind is CUPS (the printing system). LLVM and WebKit are also extremely non-trivial open source (and cross platform) contributions. Most Linux users here likely use one or two out of three of these on a weekly basis. Many likely use all three on a weekly basis. Some use all three daily.
- formerly_proven 6y ago
  Apple has removed most stuff that's needed for non-mac platforms from CUPS over the years, which are maintained by the Linux community separately now. WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink instead. LLVM is developed by many companies these days, including Intel, Sony and Google.
  - kayodelycaon 6y ago
    At least one command line tool in my toolbox uses webkit. (wkhtmltopdf)
  - floatboth 6y ago
    > Apple has removed most stuff that's needed for non-mac platforms from CUPS over the years Wrong. Upstream CUPS on Apple's github has support for everything, even systemd. > WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink GTK's WebView (and browsers like Epiphany aka GNOME Web) use WebKit, complete with Apple's web inspector / devtools.

nendroid 6y ago

That what they said about Go but the inclusion of a GC made it only popular among python like programmers.

dgellow 6y ago
And Java developers. And Ruby developers. And node developers.
- vips7L 6y ago
  Most Java devs I know wouldn't touch go. Lack of generics, proper collection classes and having to manually iterate everything isn't very attractive to people who have these features.