Swift: [question] Linux compatibility

[tanner0101]

Does this package work on non-Darwin platforms?

[dan-zheng]

Yes. Currently, we build and test on Ubuntu 14.04 and Ubuntu 16.04 and provide pre-built packages for those platforms.

Theoretically, the Swift build scripts support other non-Darwin platforms (FreeBSD, etc) but we haven't added TensorFlow support for them.

[dan-zheng]

Speaking of other platforms, we do plan on adding iOS support at some point!
TensorFlow provides iOS build instructions so it should be feasible. 😀

[coder543]

Swift is a fine language, but I would also point out that Swift doesn't support Windows... like, at all. Considering Windows is possibly the largest platform used by data scientists, that's a confusing stance to take if tensorflow is so concerned about ease of use for data scientists. WSL doesn't count, since it doesn't even give you access to the GPUs. I'm confused as to why tensorflow selected Swift over Rust, when Rust has uniformly better support for Windows and Linux than Swift. Rust also supports WASM better than any other language, with the possible exception of C, so using Rust would have furthered Google's long-term goal of supporting tensorflow on the web better than Swift is currently poised to do.

All of these problems can be resolved with enough effort, but I think it would have taken less effort to improve the ergonomics of Rust than to fix all of the issues Swift presents for tensorflow.

Swift is way more sustainable than Python, due to just how slow Python is, so I'm glad to see effort being put into this project, I just wonder if this is really the most _objective_ choice for the project. If those issues mentioned above with Swift are about to be fixed in rapid succession, then that's great! I expect Swift will be great for tensorflow users then.

[dan-zheng]

@tanner0101
One last point: I noticed you used the word "package", but Swift for TensorFlow is actually a copy of the Swift compiler that adds first-class language support for machine learning. This distinguishes Swift for TensorFlow from machine learning frameworks like PyTorch, which are implemented as libraries.

We chose this approach because we believe first-class language support enables the best of performance and usability, and will open up many research possibilities. Please read our design overview for more information.

[dan-zheng]

@coder543
We explain our rationale for choosing Swift in the "Why Swift for TensorFlow?" document.

With project requirements in mind, we considered many languages. Here's an excerpt from the document about our thoughts on Rust:

A concern with using Rust is that a strong goal of this project is to appeal to the entire TensorFlow community, which is currently pervasively Python based. We love Rust, but it has a steep learning curve that may exclude data scientists and other non-expert programmers who frequently use TensorFlow. The ownership model is really great, but mostly irrelevant to the problems faced by today’s machine learning code implemented in Python.

[rxwei]

Hi @coder543, in this document we presented our objective decision process.
Why Swift for TensorFlow?

Picking the best language design and balancing the trade-offs is a more fundamental problem. We have to take into account of the design principles of the language, e.g. progressive disclosure of complexity, which is far more important than just "what platforms the language supports". (If I considered the latter to be the deciding factor, I would've chosen C.)

The Swift open source community has worked on Windows support and bare metal support, although they are not nearly ready for general use. We'll be very happy to work with the community to develop support for more platforms at certain point.

If you have further questions regarding the language of choice, please feel free to discuss that on the mailing list. Thank you!

[coder543]

@dan-zheng Yes, I read that, but I was hoping for more elaboration around the points that I had raised.

The additional learning curve for Rust (versus Swift) is arguably small compared to the learning curve of asking data scientists to erase Windows and install a Linux distro, for example. (Running a VM won't work because direct GPU access is important.) The ownership model _really is_ irrelevant to why Rust would be a better choice here, so I agree with the document on that. The reason why Swift doesn't make sense is all about platform support, which I didn't see addressed in that document. It's easy to underestimate how much effort went into making Rust support all these major OSes as well as it does. Especially if the goal of the project is to enhance the ergonomics of a language to better support machine learning, any pain points of Rust for that purpose could be cleaned up. A fork of Rust could even (theoretically) wrap everything in Arc or Rc by default, which would remove the need to think about ownership, which is probably the biggest ergonomic pain point for a data scientist. That change seems relatively minor compared to Windows support.

I wasn't even planning to respond if any of my points had been addressed at all, but none of my points were addressed, so I felt the need to clarify here a little bit. I feel that properly supporting Windows is immensely important if Google wants to support data scientists. Supporting Linux and WASM well from day one would be an added bonus. Swift support for Linux is very minimalistic at this point.

This decision seems to have already been made, and I've stated my piece, so it's whatever. I just wanted to provide an additional perspective.

@rxwei that's kinda missing the point. Swift and Rust are very similar languages. All of the reasoning for picking Swift applies to picking Rust, but your argument is "throwing the baby out with the bathwater". C is not even remotely an equivalent language. As I've said before, Swift is a fine language. I like it far better than most, and platform support isn't _the only thing_ that matters. But it is really important that you support the platforms that are being used by your users. However, if I take your argument at face value, then between Rust and C, I would say that Rust has better support for writing a program that works correctly on Windows, Mac, and Linux. Hands down. Therefore, it actually has _better_ platform support than C. Unless you're talking about support esoteric architectures that no data scientist is actually using, which, again, is irrelevant to the discussion. JavaScript might even have better platform support than C and Rust, but that's also not the point here.

Really, I'm done now. I won't bother this team again for the near future. I hope the team can do wondrous things with Swift! I also hope the team will make the platform support better so their project will actually be useful to the target audience.

[lattner]

Thanks for the input @coder543. That document is not intended to be a debate about the suitability of languages for arbitrary purposes, it was just intended to explain the process of how we ended up here - we understand that other people coming from other perspectives would see different tradeoffs and could end up in different places.

In any case, as stated, we would really love to see the techniques applied in other languages and domains, but we're going to continue pursuing this one. Thanks!

[JacquisLewis]

Swift has the tech and momentum for the realization of an Isomorphic Development https://www.google.com/search?client=safari&rls=en&q=isomorphic+development&ie=UTF-8&oe=UTF-8 dream scenario. One language to do everything because, "Swift has the audacious goal of spanning all the way from low-level systems programming to high-level scripting,…”

Over time the language will gain all the properties to be used in any kind of development from embedded to cloud

On Apr 26, 2018, at 5:28 PM, Josh Leverette [e-mail] wrote:

Yes, I read that, but I was hoping for more elaboration around the points that I had raised.

The additional learning curve for Rust (versus Swift) is arguably small compared to the learning curve of asking data scientists to erase Windows and install a Linux distro, for example. (Running a VM won't work because direct GPU access is important.) The ownership model really is irrelevant to why Rust would be a better choice here, so I agree with the document on that. The reason why Swift doesn't make sense is all about platform support, which I didn't see addressed in that document. It's easy to underestimate how much effort went into making Rust support all these major OSes as well as it does.

I wasn't even planning to respond if any of my points had been addressed at all, but none of my points were addressed, so I felt the need to clarify here a little bit. I feel that properly supporting Windows is immensely important if Google wants to support data scientists. Supporting Linux and WASM well from day one would be an added bonus. Swift support for Linux is very minimalistic at this point.

This decision seems to have already been made, and I've stated my piece, so it's whatever.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/tensorflow/swift/issues/3#issuecomment-384828003, or mute the thread https://github.com/notifications/unsubscribe-auth/AkPaZOsgj4GrEWBnu7YXb93Qi1lTU345ks5tsmZCgaJpZM4To5EO.

[JacquisLewis]

Whoops

On Apr 26, 2018, at 6:05 PM, Chris Lattner [e-mail] wrote:

Thanks for the input @coder543 https://github.com/coder543. That document is not intended to be a debate about the suitability of languages for arbitrary purposes, it was just intended to explain the process of how we ended up here - we understand that other people coming from other perspectives would see different tradeoffs and could end up in different places.

In any case, as stated, we would really love to see the techniques applied in other languages and domains, but we're going to continue pursuing this one. Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/tensorflow/swift/issues/3#issuecomment-384833082, or mute the thread https://github.com/notifications/unsubscribe-auth/AkPaZI8InLu93nS4BFsAH1CUgwlWA3iyks5tsm7ngaJpZM4To5EO.

[iiSeymour]

@dan-zheng is there an issue/twitter account to follow to get updated on iOS support?

[lattner]

The toolchain is primarily oriented around training, not on-device inference. We are interested in hooking up TF Lite support. Please ask on the mailing list, or file a new bug to track TFLite integration, thanks!