4 ms·

OP said systems language, and what’s Swift lacking there on other platforms?

by sedatk 6y ago

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?
        zamalek 6y ago
        Because they all have 1st-party wrappers.
        saagarjha 6y ago
        Swift is adding their own as you can see, they’ve been using Foundation until now because it’s really not that bad of an interface. Also, I disagree with the claim that Rust has first-party wrappers, it barely has first-party anything to be honest.
    - andrewjl 6y ago
      In newer versions of Swift the need for almost all prefixing has been removed. You can still say it's a facade when using things like UIKit, but as we've seen in the past few years w/ SwiftUI that is changing. It's already no longer the case if you're doing anything related to heavy duty computation [Accelerate, Metal & others have Swift-specific APIs now] or networking [SwiftNIO].
  - dmitriid 6y ago
    Truly an exceptionally beautiful and polished stdlib: https://twitter.com/dmitriid/status/1201441652507844608 https://twitter.com/dmitriid/status/1201441652507844608 I especially like that you have file operations defined on String type.
    - saagarjha 6y ago
      The first two lines of your example interact with the standard library.
      - dmitriid 6y ago
        The first two lines of which version? Also, how is it that a "well-designed and polished" standard library doesn't have a means to write to a file?
        saagarjha 6y ago
        Either version. And, FWIW, a standard library that is well-designed and polished can be spartan; Swift's has been on the operating system interface side because Foundation exists.
  - pjmlp 6y ago
    That is why the Linux examples are full of import Glibc.
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.

OP said systems language, and what’s Swift lacking there on other platforms?

by sedatk 6y ago

OP said systems language, and what’s Swift lacking there on other platforms?

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?
        zamalek 6y ago
        Because they all have 1st-party wrappers.
        saagarjha 6y ago
        Swift is adding their own as you can see, they’ve been using Foundation until now because it’s really not that bad of an interface. Also, I disagree with the claim that Rust has first-party wrappers, it barely has first-party anything to be honest.
  - andrewjl 6y ago
    In newer versions of Swift the need for almost all prefixing has been removed. You can still say it's a facade when using things like UIKit, but as we've seen in the past few years w/ SwiftUI that is changing. It's already no longer the case if you're doing anything related to heavy duty computation [Accelerate, Metal & others have Swift-specific APIs now] or networking [SwiftNIO].
- dmitriid 6y ago
  Truly an exceptionally beautiful and polished stdlib: https://twitter.com/dmitriid/status/1201441652507844608 https://twitter.com/dmitriid/status/1201441652507844608 I especially like that you have file operations defined on String type.
  - saagarjha 6y ago
    The first two lines of your example interact with the standard library.
    - dmitriid 6y ago
      The first two lines of which version? Also, how is it that a "well-designed and polished" standard library doesn't have a means to write to a file?
      - saagarjha 6y ago
        Either version. And, FWIW, a standard library that is well-designed and polished can be spartan; Swift's has been on the operating system interface side because Foundation exists.
- pjmlp 6y ago
  That is why the Linux examples are full of import Glibc.

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.