4 ms·

I really wish Swift could find a way to be useful on platforms other than Apple. I'd be willing to commit more to it if I could write truly portable code in it.

I really wish Swift could find a way to be useful on platforms other than Apple. I'd be willing to commit more to it if I could write truly portable code in it. It's got a good start on Linux, but Windows and Android would be cool too. Though Kotlin won out over Swift for Android (very similar languages but I like Swift a bit better there).

pjmlp 9y ago
Any language that wishes first class support on Android needs to support a painless way to interoperate with Java APIs on their compiler toolchain. Otherwise developers are going to have lots of pain manually writting JNI wrappers to 90% of Android APIs. Likewise on Windows with COM support.
Stanleyc23 9y ago
let's say android or windows adopted swift. I don't think that would eliminate the biggest learning curve of dealing with the frameworks. in my experience, learning UIKit stuff was way trickier than swift. I imagine the same experience developing for other OS'.
- hellofunk 9y ago
  I'm talking more about portable business logic, libraries I could write and access on all platforms.
- vvanders 9y ago
  I dunno how true that is, Rust has fantastic support across Windows and Android but leaves UI framework up to the platform.
  - kobeya 9y ago
    I think that’s what he’s saying?
    - vvanders 9y ago
      Sort-a. I think frameworks are a separable problem with the platform support.
      - favorited 9y ago
        You can lump UI frameworks in with others, right?
  - pjmlp 9y ago
    I wish Rust had such fantastic support you claim. There is no support for integrated debugging, across languages on Android Studio and Visual Studio. No support for COM or UWP and Win32 is WIP. Not sure how much NDK APIs are actually wrapped.
    - Rusky 9y ago
      Those are probably what the parent means by "UI framework." The Rust toolchain does integrate seamlessly with those platforms' native toolchains, using the same binary and debug info formats. Perhaps this is perception is just caused by e.g. the extremely low bar set by MinGW, which doesn't do any of that despite "supporting" Windows.
      - pjmlp 9y ago
        Those stacks are more than just UI. For example since Longhorn failure, COM has become the major way to introduce Windows APIs, since Vista Win32 doesn't get much love.
    - vvanders 9y ago
      I hate to be a bit blunt but you're really barking up the wrong tree. VSCode debugger works fine on both msvc and mingw targets. Asking for COM or UWP is like saying that Javascript has a horrible interop story with COM/UWP. You're picking Rust to build something fast and/or low memory. Leave building a UI to the right tools. C# has a fantastic FFI and works just fine with Rust. I actually have a project using UWP and Rust together. I get all the portability of Rust and get to use UWP as the UI frontend with minimal fuss.
      - pjmlp 9y ago
        I am just raising awareness, it is all a matter if you feel like it matters to earn the hearts of. Windows developers using to their VS, C# + C++ and respective tooling productivity. Picking up your example,how do you expose and debug UWP components?
Stranger43 9y ago
It's probably going to end up similar to the equally hyped objectiveC where the core language was made portable but few of the tooling/API's used for real world OSX applications ended up supporting anything but OSX in any production ready capacity despite GNUSTEP actually shipping a ObjetiveC/OpenSTEP clone for Linux. For the time being swift on Linux is a case of a few PaaS vendors trying to product differentiate by also offering swift frameworks because they can(due to modern container wrangling) more then due to any real market demand.
- amorde 9y ago
  One of the biggest causes of this for Objective-C was the lack of the Foundation framework (a higher-level interface to Core Foundation) - but this is being reimplemented in Swift. See https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation Of course UIKit will still be missing, but thats sort of expected.
  - favorited 9y ago
    Not if Microsoft keeps this up: https://github.com/Microsoft/WinObjC/tree/develop/Frameworks/UIKit https://github.com/Microsoft/WinObjC/tree/develop/Frameworks... I'm not saying that's entirely reasonable, but it exists.
nerdface 9y ago
You can use Swift on Windows: https://github.com/apple/swift/blob/master/docs/Windows.md https://github.com/apple/swift/blob/master/docs/Windows.md
- Someone 9y ago
  https://github.com/apple/swift/blob/master/README.md https://github.com/apple/swift/blob/master/README.md: ”macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current supported host development operating systems” Also, on the page you reference: ”Note that all compiled Swift binaries are only executable within Bash on Windows and are Ubuntu, not Windows, executables.”
  - favorited 9y ago
    > macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux are the current supported host development operating systems I believe that "supported" here means the test suites and CI are run on those platforms. More importantly, any regressions on those platforms would be considered bugs. However, there have been partial or complete ports to several other platforms, including some weird ones. Aside from Apple platforms, I see code in-tree for Linux, CYGWIN, Windows, FreeBSD, PS4[0], Android, and Haiku[1] (a revived BeOS). And that's not some stray LLVM code, it's in the Swift compiler itself. I've read that there was/is an out-of-tree upstream port to some IBM mainframe hardware, as well. A bit tangential to your original point, but I think it's interesting. [0]https://github.com/apple/swift/commit/83901998c91f9242a133aab9721ede483e6b645e https://github.com/apple/swift/commit/83901998c91f9242a133aa... [1]https://github.com/apple/swift/commit/aee81d272f3147c0a9b610956e72a7c0772b8bcb https://github.com/apple/swift/commit/aee81d272f3147c0a9b610...
augbot 9y ago
https://github.com/apple/swift/blob/master/docs/Android.md https://github.com/apple/swift/blob/master/docs/Android.md This is a good start, at least for Android hardware..
- marvel_boy 9y ago
  Amazing. Thanks for the link.

pjmlp 9y ago

Any language that wishes first class support on Android needs to support a painless way to interoperate with Java APIs on their compiler toolchain. Otherwise developers are going to have lots of pain manually writting JNI wrappers to 90% of Android APIs. Likewise on Windows with COM support.

Stanleyc23 9y ago

let's say android or windows adopted swift. I don't think that would eliminate the biggest learning curve of dealing with the frameworks. in my experience, learning UIKit stuff was way trickier than swift. I imagine the same experience developing for other OS'.

hellofunk 9y ago
I'm talking more about portable business logic, libraries I could write and access on all platforms.
vvanders 9y ago
I dunno how true that is, Rust has fantastic support across Windows and Android but leaves UI framework up to the platform.
- kobeya 9y ago
  I think that’s what he’s saying?
  - vvanders 9y ago
    Sort-a. I think frameworks are a separable problem with the platform support.
    - favorited 9y ago
      You can lump UI frameworks in with others, right?
- pjmlp 9y ago
  I wish Rust had such fantastic support you claim. There is no support for integrated debugging, across languages on Android Studio and Visual Studio. No support for COM or UWP and Win32 is WIP. Not sure how much NDK APIs are actually wrapped.
  - Rusky 9y ago
    Those are probably what the parent means by "UI framework." The Rust toolchain does integrate seamlessly with those platforms' native toolchains, using the same binary and debug info formats. Perhaps this is perception is just caused by e.g. the extremely low bar set by MinGW, which doesn't do any of that despite "supporting" Windows.
    - pjmlp 9y ago
      Those stacks are more than just UI. For example since Longhorn failure, COM has become the major way to introduce Windows APIs, since Vista Win32 doesn't get much love.
  - vvanders 9y ago
    I hate to be a bit blunt but you're really barking up the wrong tree. VSCode debugger works fine on both msvc and mingw targets. Asking for COM or UWP is like saying that Javascript has a horrible interop story with COM/UWP. You're picking Rust to build something fast and/or low memory. Leave building a UI to the right tools. C# has a fantastic FFI and works just fine with Rust. I actually have a project using UWP and Rust together. I get all the portability of Rust and get to use UWP as the UI frontend with minimal fuss.
    - pjmlp 9y ago
      I am just raising awareness, it is all a matter if you feel like it matters to earn the hearts of. Windows developers using to their VS, C# + C++ and respective tooling productivity. Picking up your example,how do you expose and debug UWP components?

Stranger43 9y ago

It's probably going to end up similar to the equally hyped objectiveC where the core language was made portable but few of the tooling/API's used for real world OSX applications ended up supporting anything but OSX in any production ready capacity despite GNUSTEP actually shipping a ObjetiveC/OpenSTEP clone for Linux. For the time being swift on Linux is a case of a few PaaS vendors trying to product differentiate by also offering swift frameworks because they can(due to modern container wrangling) more then due to any real market demand.

amorde 9y ago
One of the biggest causes of this for Objective-C was the lack of the Foundation framework (a higher-level interface to Core Foundation) - but this is being reimplemented in Swift. See https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation Of course UIKit will still be missing, but thats sort of expected.
- favorited 9y ago
  Not if Microsoft keeps this up: https://github.com/Microsoft/WinObjC/tree/develop/Frameworks/UIKit https://github.com/Microsoft/WinObjC/tree/develop/Frameworks... I'm not saying that's entirely reasonable, but it exists.

nerdface 9y ago

You can use Swift on Windows: https://github.com/apple/swift/blob/master/docs/Windows.md https://github.com/apple/swift/blob/master/docs/Windows.md

Someone 9y ago
https://github.com/apple/swift/blob/master/README.md https://github.com/apple/swift/blob/master/README.md: ”macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current supported host development operating systems” Also, on the page you reference: ”Note that all compiled Swift binaries are only executable within Bash on Windows and are Ubuntu, not Windows, executables.”
- favorited 9y ago
  > macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux are the current supported host development operating systems I believe that "supported" here means the test suites and CI are run on those platforms. More importantly, any regressions on those platforms would be considered bugs. However, there have been partial or complete ports to several other platforms, including some weird ones. Aside from Apple platforms, I see code in-tree for Linux, CYGWIN, Windows, FreeBSD, PS4[0], Android, and Haiku[1] (a revived BeOS). And that's not some stray LLVM code, it's in the Swift compiler itself. I've read that there was/is an out-of-tree upstream port to some IBM mainframe hardware, as well. A bit tangential to your original point, but I think it's interesting. [0]https://github.com/apple/swift/commit/83901998c91f9242a133aab9721ede483e6b645e https://github.com/apple/swift/commit/83901998c91f9242a133aa... [1]https://github.com/apple/swift/commit/aee81d272f3147c0a9b610956e72a7c0772b8bcb https://github.com/apple/swift/commit/aee81d272f3147c0a9b610...

augbot 9y ago

https://github.com/apple/swift/blob/master/docs/Android.md https://github.com/apple/swift/blob/master/docs/Android.md This is a good start, at least for Android hardware..

marvel_boy 9y ago
Amazing. Thanks for the link.