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.
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.
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.
Yeah. I have given up on Playgrounds I just use a console app. Pity.
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
Oh, interesting, I didn't know that. Thanks!
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: [SR-7754] Generating LinuxMain breaks when renaming a test · Issue #5358 · apple/swift-package-manager · GitHub).
Isn't there also AppCode?
They also don't integrate with the SPM which is another problem if you want to play around with libraries.
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.
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.
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. 
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.
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?
Microsoft helped bring the original tensorflow to windows. Google Developers Blog: TensorFlow 0.12 adds support for Windows
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
https://www.rust-lang.org/en-US/faq.html#does-rust-have-a-runtime
Once we have great runtime support then we can worry about better tooling on windows for development.
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.
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.
@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.
I havenât built for Windows in a while, but when I last did, I wrote my process up at Swift on Windows Status - #9 by Torust.
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!
-Chris
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.