Swift as a cross-platform language and Windows support


(Félix Fischer) #21

Good point!

What's the gain of how easy are Playgrounds to use and fiddle with, if they don't help almost any platform that Swift runs in?

At least Windows (short of Linux) should have Playgrounds support. Windows and Darwin are the two largest GUI based OSes by market share. If Playgrounds were at least supported there, it would be huge for usability.

(Howard Lovatt) #22

Google have launched Android Things, their Internet of Things (IoT) platform, that puts Java/Kotlin on embedded devices. It would be great if Apple launched iotOS and along with it Swift on embedded.

(Steven Van Impe) #23

I for one will remove Playgrounds from my course entirely. There is no excuse for how buggy they are. I adopted Playgrounds from the start and enjoy how they let you mix code with documentation, but the number of hours I lose both in preparation for a class as well as during a class, is unacceptable.


I second the emotion. I find that for the most trivial of playgrounds, I have to restart Xcode to get it to rerun.

(Howard Lovatt) #25

Yeah. I have given up on Playgrounds I just use a console app. Pity.

(Joannis Orlandos) #26

I disagree with Swift being a pain to build on Linux. However, I tend to agree with the point of @svanimpe .
I know JetBrains is working on CLion, and I've heard people especially (@svanimpe) say good things about the later builds. But in reality the community should be working on some form of support, too. A paid IDE is not an option for a beginner just starting out with a new (their first?) language. I can't expect them to understand the value to begin with, let alone pay for it

(Pedro José Pereira Vieito) #27

Oh, interesting, I didn't know that. Thanks!

(Pierpaolo Frasa) #28

And I disagree with the disagreement. ;)
Try compiling on any Ubuntu version newer than the official supported ones, or, say, on another Linux distribution. Things can break in subtle ways. I haven't been able to compile Swift on Ubuntu 17.10 and could only get it onto the system by installing the 17.04 version that the vapor PPA provides: https://repo.vapor.codes/

With 18.04, there doesn't seem to be any option currently.

And the Linux pains go way beyond this. Having to maintain the LinuxMain.swift for tests is a pain and error prone (see e.g. this bug: https://bugs.swift.org/browse/SR-7754).

Isn't there also AppCode?

(Pierpaolo Frasa) #29

They also don't integrate with the SPM which is another problem if you want to play around with libraries.

(Joannis Orlandos) #30

Correct, jetbrains doesn't integrate with SPM (nor does Xcode for that matter). AFAIK, appcode is apple-only and relies on xcodebuild. I've been perfectly able to run Swift on Ubuntu all the way through 17.10. There are other options like SwiftEnv or a manual install that all work fine for me. I've just tried CLion on Ubuntu and find autocorrect working and SPM fetching as normally. It needs some minor configuration that took me ~2 minutes.

The pains on Linux are far and above known to me (I worked on the Vapor team and am an active Swift Server dev). But to say it's a pain to build it unrelated to other Linux problems.

If I'd had to list the pains in Linux they're still pretty far fetched and specific.

  • I've seen some crashes in libdispatch when doing some more advanced work back before NIO and even when we wrote our own async lib for this reason.
  • LinuxMain is a big annoyance to me and I cannot concur more than that. That is definitely a big issue and not far fetched nor specific.
  • There is a crash now and then in Foundation. I've seen it happen once every few weeks in some applications, but it's far fetched enough that it doesn't happen often/consistently and it almost never able to be traced.
  • Debug compilation has (had) some bugs with the Vapor BCrypt implementation specificially where some mathematical operations were incredibly slow and you had to run release to get a normal performance.
  • Foundation was previously very unreliable on Linux. Aside from NSUnimplemented there were occasions like Base64 being unusable and very commonly crashing. This was also a problem with a few other features.

Almost all of the above issues aren't a problem anymore on Linux through other libraries such as NIO or community libs. I'd go as far as to say Swift on Linux as an ecosystem is more reliable and mature than iOS. I'd say iOS has a huge technical Objective-C background to carry with it which is extremely noticable all throughout the development of an iOS app. I've seen Xcode crash in InterfaceBuilder on dragging a TableCell into an XIB.

These things are apparently acceptable for iOS development, but Swift on Linux is getting a huge amount of complaints being more reliable, performant and active than iOS development. I'd say apple did a top-notch job on Linux support.

Back to topic; I don't stand to gain (much) from Windows support. I wouldn't use it I think. But I'd love to see Swift on Windows for the sake of Swift being a great language and that Swift GUI apps would be easy to make cross-platform. If they do plan to support Windows, I honestly hope it becomes as good as Linux.

(Ron Olson) #31

I've been building Swift for Fedora and have a request out to make it available in the official repository: https://bugzilla.redhat.com/show_bug.cgi?id=1536780. I've been using Swift more on Fedora Linux than I have on the Mac. :sunglasses:

(Jon Shier) #32

I guess my ultimate point is that Apple should be driving Swift cross platform and not relying on random interested individuals or organizations to do it. If they're really committed to the language, then increased investment across all platforms will ultimately pay off for even internal Apple projects. Otherwise, even interested individuals will eventually get frustrated by Apple's lack of interest and the language will stagnate outside of features driven by Apple. And this is just the language, the tooling is a whole separate issue where, again, Apple should be leading the way and not letting Swift languish under Apple's internal release schedule.

(Karl) #33

It’s easy to tell other people what to do, but really, how Apple allocate their engineering resources is a matter for them alone to decide. You can try emailing Tim Cook, but you shouldn’t get annoyed that Windows support isn’t a priority for them.

You could also argue that Microsoft should invest in Swift support for their platforms. Why don’t you ask them?

(Chéyo Jiménez) #34

Microsoft helped bring the original tensorflow to windows. https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html

Since then Microsoft has invested a lot more time on homegrown AI tools, I do not think they would allocate any resources for tools like Swift for TF to run on Windows.

I wonder how complicated is Swift’s runtime compared with rust’s running on windows

Once we have great runtime support then we can worry about better tooling on windows for development.

(Zach Wolfe) #35

Why the sarcasm? Apple makes its own decisions, but it doesn't make them in a vacuum. Criticism is the only way people on the outside can effect change in a big company like Apple.

(Karl) #36

No sarcasm. Like any company, Apple only has finite engineering resources, and perhaps they view things like ABI stability as more strategically useful for them. Maybe they will consider porting to Windows, but we can't demand it.

(Spencer Kohan) #37

@Troust any chance you will document your process and publish an article about how you do this? I am very interested in the topic as I am trying to do the same.

(Thomas Roughton) #38

I haven’t built for Windows in a while, but when I last did, I wrote my process up at Swift on Windows Status.

(Chris Lattner) #39

FWIW, the Swift for TensorFlow team is actively looking to hire an engineer to work on Swift for Windows and help drive surrounding ecosystem efforts but are struggling with finding someone who is interested and able. If you know of anyone who could be a good fit, please get in touch with @bgogul or I - please don't post to this thread though, it would be OT. Thanks!


(Saleem Abdulrasool) #40

The build on Windows can be accomplished, but it is pretty fragile. It is significantly better if you use clang instead of MSVC to build the tools. It becomes even better if you cross-compile the windows hosted toolchain from Linux. At least a basic sanity check of the generated compiler and standard library shows that things are working. There are still some rough edges, so if there are people who are trying to actually test this, I would love to get feedback on what things break so that we can get those addressed. I think that the test suite is going to be a larger effort.

I know that the recent ABI work has broken the build, but I have been trying to keep up and fix things as I find them. Most of the patches for this are on GitHub and I'm working towards getting them merged.