18 ms·

Swift on Windows

325 points by gok 6y ago

rudedogg 6y ago
I didn’t know about the effort to be able to create GUIs on Windows. It looks like there are basic wrappers for a lot of controls too: https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a83ee77fcecdc2570cf24355e4/Sources/UI https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a... Slightly OT: I wish people wouldn’t put such large license headers in source code. I just don’t see the point, and it’s often longer than the actual source!
- geraldcombs 6y ago
  > Slightly OT: I wish people wouldn’t put such large license headers in source code. There's an ongoing effort to fix this: https://www.linuxfoundation.org/blog/2018/08/solving-license-compliance-at-the-source-adding-spdx-license-ids/ https://www.linuxfoundation.org/blog/2018/08/solving-license...
- zerr 6y ago
  I hope wxSwift project will be resurrected.
longstation 6y ago
I hope one day they could bring the same (GUI support) to Linux.
melling 6y ago
I’ve got a Swift Cookbook on GitHub. Some might find it helpful: https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook
Gys 6y ago
Swift for Android would be a real milestone. There are not so many mainstream cross mobile development platforms.
- JamesSwift 6y ago
  Xamarin
  - akmarinov 6y ago
    Kotlin Native React Native
    - JamesSwift 6y ago
      Ehh, kotlin MPP isn't far enough along for me yet. I'm biased against JS-based approaches. Xamarin is the best current option in my (very biased) opinion EDIT: but kotlin MPP is my long term hope. Once they iron out the kinks (e.g. ios coroutines)
      - nwienert 6y ago
        I was skeptical of React native especially having tried it a few years ago, but new versions are incredibly nice. Plus, it’s running JS off thread. Performance has been fantastic. I rewrote recently an app in SwiftUI - the React Native app was faster and easier to write. Which was a surprise to me because I like the SwiftUI components more, but in the end the far superior hot reloading and far better dev tools, along with the much better flexibility (less time “getting the code/types to run”) meant I was moving about 5-10x faster. Finally, we are sharing almost 100% of code across native and web. We built a component kit designed to use react-native-web and that handles just a few edge cases, and the net result is quite awesome. We do obviously have it designed to look different when mobile, but it’s the exact same as the web responsive mobile. The web version adapts nicely based on screen size as well. So unlike Flutter you’re not having to deliver a massive web bundle with tons of incompatibilities and perf issues. And unlike any other language you’re fully cross platform. I ran it for the first time the other day on Android just to test if it worked and it did first try, no code change necessary. I’ve definitely changed my opinion - React is not just viable, but preferred to me, even if I could theoretically move as fast with a native app in each language.
        6y ago
pjmlp 6y ago
> For the ones interested in working on core tooling, there is plenty of work to be done to improve the debugger and to improve the Windows support in the Swift Package Manager. We invite you to check out the Swift Bug Tracker for the current issues and to send patches to the GitHub repositories. Poor Apple, budget cuts have been hit really hard.
- onelovetwo 6y ago
  this is actually a community project, the guy behind all this (Saleem) isnt even at Apple, hes at Google.
  - the_duke 6y ago
    Is it just a hobby project, or actually sponsored by Google? They are trying to push Swift for Tensorflow [1], so proper upstream cross-platform capability would probably be important to them. [1] https://www.tensorflow.org/swift https://www.tensorflow.org/swift
    - deleted 6y ago
      [deleted]
    - patrec 6y ago
      Not really. Google hired LLVM and Swift dude for ML stuff. LLVM and Swift dude decided that although Google already had some LLVM, it still needed more Swift, and for ML specifically. This must have struck probably the majority of people in ML who are not him as slightly bizarre (notable exception: Jeremy Howard). Now he's left. I would be truly amazed if Swift for ML goes anywhere.
    - nl 6y ago
      It's pretty clear that since Chris Lattner left Google the Swift Tensorflow version isn't really going anywhere.
      - dklend122 6y ago
RcouF1uZ4gsC 6y ago
This is really cool. I have been watching Swift with interest mainly because it is an answer to the question: How would a bunch of C++ experts (for example Doug Gregor and David Abrahams) design a language if they could do it all over again? Before, the lack of a good cross-platform story kept me away. Now, I think this gives me an excuse to play around with Swift.
- skohan 6y ago
  It's a really nice language. IMO the main limitations currently are: 1. version/dependency management is a bit of a pain. Every time there's a major language update I have to do surgery on my larger swift projects 2. ARC-based memory managements has some serious pitfalls in terms of worst-case performance characteristics. But in terms of syntax and general philosophy, I have never found a language more pleasant to work with than Swift
thought_alarm 6y ago
I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped around the old Win32 APIs, like it's 1999. (Nor Hungarian Notation). I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.
- ryanmarsh 6y ago
  Windows dev is a superfund site
  - dylan604 6y ago
    I always heard it was a dumpster fire, but you've upped the ante by calling it a toxic waste site. Nice. I don't think I have heard a more appropriate description.
    - LegitShady 6y ago
      A delinquent toxic waste site even
- chin7an 6y ago
  I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS. [0] - https://docs.microsoft.com/en-us/windows/apps/desktop/ https://docs.microsoft.com/en-us/windows/apps/desktop/
  - thought_alarm 6y ago
    I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.
    - ratww 6y ago
      Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.
oseph 6y ago
I really like Swift. Recently I've been using it as my "main" language in developing a macOS user interface for my MSc research project, and it has literally made developing fun! Great to see it getting more support outside of the Apple domain.
- non-entity 6y ago
  I wrote some swift maybe 4 or 5 years ago when I was doing mobile app stuff and had access to a Mac. I remember finding the language pretty enjoyable, but considered its xplat potential questionable. At the time, I believe it did run on linux and people were touting it as a solid platform for building server side applications. I dont think that was ever realized though.
  - mrtksn 6y ago
    Swift on a server is a think: https://vapor.codes https://vapor.codes
    - jamil7 6y ago
      The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.
      - mrtksn 6y ago
        I was going use it only if there there was an official Firebase support to do things the way they are done on iOS. What I want is to have a server app that communicates with with Firebase services to do certain tasks. Doing this in Javascript(Node) instead, is very cognitively taxing for me. Mental models are different, so I need to “cool down” and start thinking in the other language when switching between app dev / back end. Swift is so nice That i would rather do everything in it anyway but not having to switch mental models is the real reason.
jabofh 6y ago
To abuse an old meme: "...yes, but does it run on Linux..." It seems like Windows already has a glut of similar tools; if you wanted to make a real impact with a fairly new language, which Swift is, with massive corporate backing, which Swift has, the one would think Linux would be a far more opportune destination for an effort like this.
- sjm 6y ago
  There are already multiple Linux toolchains available, Windows is just catching up: https://swift.org/download/ https://swift.org/download/
- jeremymcanally 6y ago
  It already works on Linux (quite well, actually): https://swift.org/download/#releases https://swift.org/download/#releases
- skohan 6y ago
  It has run on windows for years. It's fairly limited in terms of distro support, but this is a stated goal for Swift 6.
  - armadsen 6y ago
    Presumably "windows" was a typo, and you meant Linux instead, but to be clear, official support for Swift on native (ie. not WSL) Windows is new in this release, and is largely the work of Saleem Abdulrasool who wrote the linked blog post.
    - skohan 6y ago
      Yes I did mean linux, thanks for the correction
- swebs 6y ago
  Yes, it had official Linux support since 2015.
- 6y ago
jarjoura 6y ago
Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist. I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work. This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries. So on the one hand, if you're a fan of Swift, you have yourself a nice hobby language you can play with on the weekend on your gaming PC. On the other, I'm not entirely sure what the point of this effort is for?!
- dsabanin 6y ago
  This is a good example of the point for this effort: https://sparkmailapp.com/blog/swift-windows https://sparkmailapp.com/blog/swift-windows
  - jarjoura 6y ago
    Sure, I guess if they feel the open source versions of Swift's standard library are functional enough to release production quality software. Keep in mind, the UI code will be completely custom for Windows though.
    - criddell 6y ago
      > the UI code will be completely custom for Windows though So Swift programs on Windows will actually look and feel like a Windows program? Good.
      - 6y ago
worik 6y ago
Why?
- worik 6y ago
  I have been using Swift for a month, so I am a beginner. It has some modern features, but it is lacking any real sense of community and feels very incomplete. Its threading and IPC models are clunky and its network code makes XMLHttp Moving from Linux to Apple development has been a shock: All the gate keeping to keep me out of their hardware - after a month I still cannot reliably put my code on iOS - not for technical reasons but for license reasons. Swift really suffers for coming from this environment. IMO leave it alone unless you have to develop for Apple hardware - and if you have to develop for Apple hardware - that is a business problem and you need to solve it.
  - armadsen 6y ago
    As part of the Swift community (and the Objective-C and Mac/iOS community for years before that), I disagree that there's no community around Swift. I think the problem is that it's still very Apple platforms focused. If you're an iOS developer, you'll find a big community, and one that has been focused on Swift specifically for the past 6 years (to the point that there are complaints about that, e.g. https://twitter.com/phughes/status/1307024158275112965 https://twitter.com/phughes/status/1307024158275112965). There are many conferences every year (well, until this year), plenty of people on Twitter, blogs, multiple community Slack teams, etc. Just in my local area (metro area of ~2 million) we have a 750 person strong, very active Slack team for iOS/Mac/Swift development, and two separate monthly in-person meetup groups (again, before COVID). If I were a Swift developer focused on Linux or Windows, though, it'd be a whole different story. The author of the linked blog post is a member of the Swift core team, and did most of the work to bring Swift to Windows himself, but outside of him, I don't really know anyone particularly focused on it. (I've also made a very decent living for 15 years developing almost exclusively for Apple platforms, so I disagree with your last paragraph too, but that's another thing altogether.)
- sedatk 6y ago
  Taking a wild guess here but Windows having the 78% of desktop OS marketshare in the world might be a reason.
leonjza 6y ago
I really hope this means a reworked iTunes / Music app for Windows soon.
- saagarjha 6y ago
  I’d sooner expect a wrapper of the website.
zerr 6y ago
The toolchain requires Win10 - but can a resulting executable be deployed on Win7?
- zapzupnz 6y ago
  I'd be surprised if it could. Mainstream support for Windows 7 ended years ago, extended support ended this year. If the Swift community (or more accurately, the one guy in charge of the Windows port) bothers to support executables running on a deprecated version of Windows, that would come as a mighty surprise to me. Still, you never know, it might manage to do it by fluke!
  - ifmpx 6y ago
    Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested. Another benefit of a community-driven language as aposed to a corporate-controlled one.
    - zapzupnz 6y ago
      Or more likely because Rust was developed to support Windows 7 before it was deprecated; Swift never targeted Windows 7. Swift was open sourced in 2015, the year when Windows 7's mainstream support ended; at that time, Swift only targeted Mac OS X and Ubuntu. Rust began as a project in 2010, Windows 7 was released in 2009.
      - raphlinus 6y ago
        I think GP's comment is fair. The portability of Rust is of a completely different order of magnitude than Swift. I mean, people have actually gotten it running on Windows 98 SE. And on Windows, Rust has access to a rich winapi surface, nice COM wrappers (including semi-official support through Microsoft's com-rs), a WinRT projection. Not to mention that crates basically just work. Maybe it isn't a first-class supported language for Windows just yet, but it's starting to feel pretty close.
alexashka 6y ago
I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose. For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for each platform. Elements compiler [0] seems to do just that. Does anyone have experience using it in production? Why is this not being adopted as a viable cross platform solution? [0] https://www.elementscompiler.com/elements/#platforms https://www.elementscompiler.com/elements/#platforms
- jug 6y ago
  Sounds a bit like developing in Haxe: https://haxe.org https://haxe.org
  - alexashka 6y ago
    Haxe seems to have no Swift or Kotlin support :( I'd be curious to know why that is, given that once you have a few languages working, adding more on, intuitively (I have no experience in this) wouldn't be too difficult, given how many features the languages share?
    - ckok 6y ago
      Sort of. I can't comment on Kotlin, but Swift is a different beast though. Swift's generics are very different from say c#, java or even c++ templates, especially when you mix them with protocol associated types, which are also sort of, but not exactly generics. In Elements we spent a lot of time on getting it right, and I think we have most edge cases covered for user code. The way generics are used in the Swift runtime library seems impossible to map perfectly on top of the concept of generics as C# has them though.
- bsaul 6y ago
  I have the impression that « finding cross platform librairies » for every types of I/O is actually a very very painful step, judging by the time it takes to get the swift stdlib work across all platform. The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.
olliej 6y ago
I couldn’t tell from the article but is going to support a COM bridge similar to the existing objc bridge?
ww520 6y ago
This is huge. This makes Swift a viable cross platform language, especially for non-gui apps.
mastrsushi 6y ago
Using a language on Windows that is intended for writing software for Apple products is as ridiculous as using C# on macOS.
- syspec 6y ago
  Unity entered the chat
  - mastrsushi 6y ago
    Unity is designed to be cross platform. Let me know when you develop a real macOS desktop application in C#.
    - athms 6y ago
      TheBrain is written in C# for Windows, MacOS, iOS, and Android. https://www.thebrain.com https://www.thebrain.com FYI -- You may want to take your head out of your ass.
jerrygoyal 6y ago
so swift is going cross platform, what would be the final size of executable and how much ram would it take to run as compared to electron? Can we say there's a slight possibility that devs would prefer swift over electron for desktop apps?
Tainnor 6y ago
I was working on a server-side project written in Swift (not my language choice) for 2 years before switching to my current company where I mostly write Kotlin. There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.
baumatron 6y ago
It's great to see more languages supported across more operating systems, though outside of iOS app development I am exceedingly dubious of the usefulness of Swift.
wdb 6y ago
I have been developing for Windows in Swift for years ️

325 points by gok 6y ago

I didn’t know about the effort to be able to create GUIs on Windows. It looks like there are basic wrappers for a lot of controls too: https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a83ee77fcecdc2570cf24355e4/Sources/UI https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a... Slightly OT: I wish people wouldn’t put such large license headers in source code. I just don’t see the point, and it’s often longer than the actual source!

geraldcombs 6y ago
> Slightly OT: I wish people wouldn’t put such large license headers in source code. There's an ongoing effort to fix this: https://www.linuxfoundation.org/blog/2018/08/solving-license-compliance-at-the-source-adding-spdx-license-ids/ https://www.linuxfoundation.org/blog/2018/08/solving-license...
zerr 6y ago
I hope wxSwift project will be resurrected.

longstation 6y ago

I hope one day they could bring the same (GUI support) to Linux.

melling 6y ago

I’ve got a Swift Cookbook on GitHub. Some might find it helpful: https://github.com/melling/SwiftCookBook https://github.com/melling/SwiftCookBook

Gys 6y ago

Swift for Android would be a real milestone. There are not so many mainstream cross mobile development platforms.

JamesSwift 6y ago
Xamarin
- akmarinov 6y ago
  Kotlin Native React Native
  - JamesSwift 6y ago
    Ehh, kotlin MPP isn't far enough along for me yet. I'm biased against JS-based approaches. Xamarin is the best current option in my (very biased) opinion EDIT: but kotlin MPP is my long term hope. Once they iron out the kinks (e.g. ios coroutines)
    - nwienert 6y ago
      I was skeptical of React native especially having tried it a few years ago, but new versions are incredibly nice. Plus, it’s running JS off thread. Performance has been fantastic. I rewrote recently an app in SwiftUI - the React Native app was faster and easier to write. Which was a surprise to me because I like the SwiftUI components more, but in the end the far superior hot reloading and far better dev tools, along with the much better flexibility (less time “getting the code/types to run”) meant I was moving about 5-10x faster. Finally, we are sharing almost 100% of code across native and web. We built a component kit designed to use react-native-web and that handles just a few edge cases, and the net result is quite awesome. We do obviously have it designed to look different when mobile, but it’s the exact same as the web responsive mobile. The web version adapts nicely based on screen size as well. So unlike Flutter you’re not having to deliver a massive web bundle with tons of incompatibilities and perf issues. And unlike any other language you’re fully cross platform. I ran it for the first time the other day on Android just to test if it worked and it did first try, no code change necessary. I’ve definitely changed my opinion - React is not just viable, but preferred to me, even if I could theoretically move as fast with a native app in each language.
      - 6y ago

pjmlp 6y ago

> For the ones interested in working on core tooling, there is plenty of work to be done to improve the debugger and to improve the Windows support in the Swift Package Manager. We invite you to check out the Swift Bug Tracker for the current issues and to send patches to the GitHub repositories. Poor Apple, budget cuts have been hit really hard.

onelovetwo 6y ago
this is actually a community project, the guy behind all this (Saleem) isnt even at Apple, hes at Google.
- the_duke 6y ago
  Is it just a hobby project, or actually sponsored by Google? They are trying to push Swift for Tensorflow [1], so proper upstream cross-platform capability would probably be important to them. [1] https://www.tensorflow.org/swift https://www.tensorflow.org/swift
  - deleted 6y ago
    [deleted]
  - patrec 6y ago
    Not really. Google hired LLVM and Swift dude for ML stuff. LLVM and Swift dude decided that although Google already had some LLVM, it still needed more Swift, and for ML specifically. This must have struck probably the majority of people in ML who are not him as slightly bizarre (notable exception: Jeremy Howard). Now he's left. I would be truly amazed if Swift for ML goes anywhere.
  - nl 6y ago
    It's pretty clear that since Chris Lattner left Google the Swift Tensorflow version isn't really going anywhere.
    - dklend122 6y ago

RcouF1uZ4gsC 6y ago

This is really cool. I have been watching Swift with interest mainly because it is an answer to the question: How would a bunch of C++ experts (for example Doug Gregor and David Abrahams) design a language if they could do it all over again? Before, the lack of a good cross-platform story kept me away. Now, I think this gives me an excuse to play around with Swift.

skohan 6y ago
It's a really nice language. IMO the main limitations currently are: 1. version/dependency management is a bit of a pain. Every time there's a major language update I have to do surgery on my larger swift projects 2. ARC-based memory managements has some serious pitfalls in terms of worst-case performance characteristics. But in terms of syntax and general philosophy, I have never found a language more pleasant to work with than Swift

thought_alarm 6y ago

I haven't done Windows development in over 10 years, but I really wasn't expecting to see what appears to be a stripped down implementation of AppKit wrapped around the old Win32 APIs, like it's 1999. (Nor Hungarian Notation). I thought WPF or WinRT or UWP was supposed to have replaced Win32 by now.

ryanmarsh 6y ago
Windows dev is a superfund site
- dylan604 6y ago
  I always heard it was a dumpster fire, but you've upped the ante by calling it a toxic waste site. Nice. I don't think I have heard a more appropriate description.
  - LegitShady 6y ago
    A delinquent toxic waste site even
chin7an 6y ago
I don't do any desktop development or use Windows much for that matter, but it looks like as of today, there are at least 4 ways [0] to build Windows desktop apps. No wonder the UX feels far less consistent and enjoyable than macOS. [0] - https://docs.microsoft.com/en-us/windows/apps/desktop/ https://docs.microsoft.com/en-us/windows/apps/desktop/
- thought_alarm 6y ago
  I suppose if Swift can only interoperate with C APIs, Win32 would be the only option.
  - ratww 6y ago
    Well, Swift uses LLVM, so it's possible to link it to C++ code with extern "C" declarations.

oseph 6y ago

I really like Swift. Recently I've been using it as my "main" language in developing a macOS user interface for my MSc research project, and it has literally made developing fun! Great to see it getting more support outside of the Apple domain.

non-entity 6y ago
I wrote some swift maybe 4 or 5 years ago when I was doing mobile app stuff and had access to a Mac. I remember finding the language pretty enjoyable, but considered its xplat potential questionable. At the time, I believe it did run on linux and people were touting it as a solid platform for building server side applications. I dont think that was ever realized though.
- mrtksn 6y ago
  Swift on a server is a think: https://vapor.codes https://vapor.codes
  - jamil7 6y ago
    The docs are very incomplete and common third party dependencies are missing. I know it’s a chicken and egg type situation but vapor is not an appealing option for backend unless you really want/need to use Swift.
    - mrtksn 6y ago
      I was going use it only if there there was an official Firebase support to do things the way they are done on iOS. What I want is to have a server app that communicates with with Firebase services to do certain tasks. Doing this in Javascript(Node) instead, is very cognitively taxing for me. Mental models are different, so I need to “cool down” and start thinking in the other language when switching between app dev / back end. Swift is so nice That i would rather do everything in it anyway but not having to switch mental models is the real reason.

jabofh 6y ago

To abuse an old meme: "...yes, but does it run on Linux..." It seems like Windows already has a glut of similar tools; if you wanted to make a real impact with a fairly new language, which Swift is, with massive corporate backing, which Swift has, the one would think Linux would be a far more opportune destination for an effort like this.

sjm 6y ago
There are already multiple Linux toolchains available, Windows is just catching up: https://swift.org/download/ https://swift.org/download/
jeremymcanally 6y ago
It already works on Linux (quite well, actually): https://swift.org/download/#releases https://swift.org/download/#releases
skohan 6y ago
It has run on windows for years. It's fairly limited in terms of distro support, but this is a stated goal for Swift 6.
- armadsen 6y ago
  Presumably "windows" was a typo, and you meant Linux instead, but to be clear, official support for Swift on native (ie. not WSL) Windows is new in this release, and is largely the work of Saleem Abdulrasool who wrote the linked blog post.
  - skohan 6y ago
    Yes I did mean linux, thanks for the correction
swebs 6y ago
Yes, it had official Linux support since 2015.
6y ago

jarjoura 6y ago

Swift has this weird sort of ecosystem where Apple builds much of the platform in a very secret (most of the roadmap isn't shared), closed-source variant for its own OS. Then it has this open source version, with a very public compiler (roadmap IS shared) that allows cross platform toolchains like this one to exist. I call it out as weird because take SwiftUI for example, the main excuse Apple engineers gave for why SwiftUI itself is closed-source is because a lot of important code lives inside of UIKit/AppKit. Huh?! Apple being Apple, each revision of SwiftUI is now glued to a singular release of a major revision of the OS. Instead, if Apple decided to built SwiftUI entirely in the open, then the foundational APIs that are closed-source would have to co-exist with the open source versions in order to work. This is in contrast to Rust, another LLVM language ported to Windows. Every part of Rust is open source and is built to work with open roadmaps and very thoroughly documented standard libraries. So on the one hand, if you're a fan of Swift, you have yourself a nice hobby language you can play with on the weekend on your gaming PC. On the other, I'm not entirely sure what the point of this effort is for?!

dsabanin 6y ago
This is a good example of the point for this effort: https://sparkmailapp.com/blog/swift-windows https://sparkmailapp.com/blog/swift-windows
- jarjoura 6y ago
  Sure, I guess if they feel the open source versions of Swift's standard library are functional enough to release production quality software. Keep in mind, the UI code will be completely custom for Windows though.
  - criddell 6y ago
    > the UI code will be completely custom for Windows though So Swift programs on Windows will actually look and feel like a Windows program? Good.
    - 6y ago

worik 6y ago

Why?

worik 6y ago
I have been using Swift for a month, so I am a beginner. It has some modern features, but it is lacking any real sense of community and feels very incomplete. Its threading and IPC models are clunky and its network code makes XMLHttp Moving from Linux to Apple development has been a shock: All the gate keeping to keep me out of their hardware - after a month I still cannot reliably put my code on iOS - not for technical reasons but for license reasons. Swift really suffers for coming from this environment. IMO leave it alone unless you have to develop for Apple hardware - and if you have to develop for Apple hardware - that is a business problem and you need to solve it.
- armadsen 6y ago
  As part of the Swift community (and the Objective-C and Mac/iOS community for years before that), I disagree that there's no community around Swift. I think the problem is that it's still very Apple platforms focused. If you're an iOS developer, you'll find a big community, and one that has been focused on Swift specifically for the past 6 years (to the point that there are complaints about that, e.g. https://twitter.com/phughes/status/1307024158275112965 https://twitter.com/phughes/status/1307024158275112965). There are many conferences every year (well, until this year), plenty of people on Twitter, blogs, multiple community Slack teams, etc. Just in my local area (metro area of ~2 million) we have a 750 person strong, very active Slack team for iOS/Mac/Swift development, and two separate monthly in-person meetup groups (again, before COVID). If I were a Swift developer focused on Linux or Windows, though, it'd be a whole different story. The author of the linked blog post is a member of the Swift core team, and did most of the work to bring Swift to Windows himself, but outside of him, I don't really know anyone particularly focused on it. (I've also made a very decent living for 15 years developing almost exclusively for Apple platforms, so I disagree with your last paragraph too, but that's another thing altogether.)
sedatk 6y ago
Taking a wild guess here but Windows having the 78% of desktop OS marketshare in the world might be a reason.

leonjza 6y ago

I really hope this means a reworked iTunes / Music app for Windows soon.

saagarjha 6y ago
I’d sooner expect a wrapper of the website.

zerr 6y ago

The toolchain requires Win10 - but can a resulting executable be deployed on Win7?

zapzupnz 6y ago
I'd be surprised if it could. Mainstream support for Windows 7 ended years ago, extended support ended this year. If the Swift community (or more accurately, the one guy in charge of the Windows port) bothers to support executables running on a deprecated version of Windows, that would come as a mighty surprise to me. Still, you never know, it might manage to do it by fluke!
- ifmpx 6y ago
  Not to turn this into a contest but Rust officially supports windows 7. In fact I believe Rust fully supported windows XP too until very recently when they decreased platform support to supported-but-unbuilt-and-untested. Another benefit of a community-driven language as aposed to a corporate-controlled one.
  - zapzupnz 6y ago
    Or more likely because Rust was developed to support Windows 7 before it was deprecated; Swift never targeted Windows 7. Swift was open sourced in 2015, the year when Windows 7's mainstream support ended; at that time, Swift only targeted Mac OS X and Ubuntu. Rust began as a project in 2010, Windows 7 was released in 2009.
    - raphlinus 6y ago
      I think GP's comment is fair. The portability of Rust is of a completely different order of magnitude than Swift. I mean, people have actually gotten it running on Windows 98 SE. And on Windows, Rust has access to a rich winapi surface, nice COM wrappers (including semi-official support through Microsoft's com-rs), a WinRT projection. Not to mention that crates basically just work. Maybe it isn't a first-class supported language for Windows just yet, but it's starting to feel pretty close.

alexashka 6y ago

I'm more interested in a compiler that takes any of these languages (C#, Kotlin, Swift) that do the same thing slightly differently, converts them into a lowest common denominator language that can then compile into any target I choose. For example write code in Swift, compile to X, compile to Kotlin. Voila, I have cross platform code, just need to write some cross platform libraries that wrap UI, networking, etc for each platform. Elements compiler [0] seems to do just that. Does anyone have experience using it in production? Why is this not being adopted as a viable cross platform solution? [0] https://www.elementscompiler.com/elements/#platforms https://www.elementscompiler.com/elements/#platforms

jug 6y ago
Sounds a bit like developing in Haxe: https://haxe.org https://haxe.org
- alexashka 6y ago
  Haxe seems to have no Swift or Kotlin support :( I'd be curious to know why that is, given that once you have a few languages working, adding more on, intuitively (I have no experience in this) wouldn't be too difficult, given how many features the languages share?
  - ckok 6y ago
    Sort of. I can't comment on Kotlin, but Swift is a different beast though. Swift's generics are very different from say c#, java or even c++ templates, especially when you mix them with protocol associated types, which are also sort of, but not exactly generics. In Elements we spent a lot of time on getting it right, and I think we have most edge cases covered for user code. The way generics are used in the Swift runtime library seems impossible to map perfectly on top of the concept of generics as C# has them though.
bsaul 6y ago
I have the impression that « finding cross platform librairies » for every types of I/O is actually a very very painful step, judging by the time it takes to get the swift stdlib work across all platform. The « low level language » is actually LLVM intermediate language, and LLVM already support building for all the major targets.

olliej 6y ago

I couldn’t tell from the article but is going to support a COM bridge similar to the existing objc bridge?

ww520 6y ago

This is huge. This makes Swift a viable cross platform language, especially for non-gui apps.

mastrsushi 6y ago

Using a language on Windows that is intended for writing software for Apple products is as ridiculous as using C# on macOS.

syspec 6y ago
Unity entered the chat
- mastrsushi 6y ago
  Unity is designed to be cross platform. Let me know when you develop a real macOS desktop application in C#.
  - athms 6y ago
    TheBrain is written in C# for Windows, MacOS, iOS, and Android. https://www.thebrain.com https://www.thebrain.com FYI -- You may want to take your head out of your ass.

jerrygoyal 6y ago

so swift is going cross platform, what would be the final size of executable and how much ram would it take to run as compared to electron? Can we say there's a slight possibility that devs would prefer swift over electron for desktop apps?

Tainnor 6y ago

I was working on a server-side project written in Swift (not my language choice) for 2 years before switching to my current company where I mostly write Kotlin. There are some aspects where Swift is nicer in theory (e.g. Swift enums beat Kotlin sealed classes in terms of ergonomics and, while unnecessary for 99% of projects, we had some genuine use case for custom operators, working on a maths product). But other than those, it seems to be that Kotlin is the superior language in almost every respect. It seems to have none of the major flaws that Swift has, and the tooling is great, which is the exact opposite of my experience with Swift.

baumatron 6y ago

It's great to see more languages supported across more operating systems, though outside of iOS app development I am exceedingly dubious of the usefulness of Swift.

wdb 6y ago

I have been developing for Windows in Swift for years ️