Hacker News new | ask | show | jobs
by pjmlp 2341 days ago
It will most likely fade away.

Swift for Tensorflow could never be taken seriously outside Apple community.

On Linux, Foundation barely works and one still needs to selectively do either import Darwin or import Glibc for basic IO stuff.

Then we are already at Swift 5.1, and Windows version has to be built from source will lots of caveats.

How can it even be taken seriously against Julia, Tensorflow for C++, ML.NET all of which work across macOS, Linux and Windows as of today, and offer the same strong typing benefits?

5 comments

While I agree there is an even chance that Google will allow S4TF to fade away after Lattner's departure, that is more of a reflection on the company having no commitment or consistency to good ideas: ex: https://gcemetery.co

However S4TF should be taken seriously if you understand what they are trying to accomplish and how deeply they designed machine learning support into the language. Take a look at http://fast.ai new course offerings using S4TF. Swift has always been a long bet. If it doesn't work as you want it, is still short sighted to discount it in the future.

also: https://twitter.com/JokerEph/status/1221831507351748608

I will count on it, when it isn't used to sell Google VMs and works on my machine as easy as Julia and ML.NET work today.

I wasn't even aware of http://fast.ai's existence.

With all due reference to Jeremy and Fast.AI (which I love and continue to recommend) I think it's fair to say they don't stick with things for a long time. I think the Fast.AI python library has been re-written 3 times in the past 3 years (Keras -> PyTorch -> PyTorch, differently).
The Swift core team just added two new members, whose contributions are related to Swift on Windows, and Swift on the server respectively, and have specifically called out supporting Swift in non-Apple domains as a part of the roadmap for Swift 6 (including adding the autodiff work from S4TF into mainline Swift). There is attention being paid to these issues.
Thanks for the heads up, I have been looking at that thread, the roadmap still looks quite uncertain, with big questions regarding what Apple is willing to support outside their platforms, tooling (e.g. IDE support), dependencies to WWDC announcements and deliveries.
I have not tried it myself, but I've heard reports that Swift LSP support is going quite well, and it's possible to develop on Ubuntu using VSCode.
I love the idea of Swift for Tensorflow : powerful automatic differentiation and a solid type system in a single language. That's something that is not seen elsewhere and that would make it a perfect fit to write deep learning code targeting production systems.

Now the language needs two things in order to be safe from an hypothetical abandon from Google : - running smoothly on linux (I though it was already there but your post seem to imply that it is not the case) - getting the auto-diff out of the alpha stage where people can build framework on top of it (fastai seem to be ready to jump on that ball which is nice)

Here,

https://swift.org/getting-started/#using-the-repl

> On macOS

    1> import Darwin
    2> arc4random_uniform(10)
    $R0: UInt32 = 4
> On Linux

    1> import Glibc
    2> random() % 10
    $R0: Int32 = 4
Any of the languages that Swift is competing against, doesn't need to have OS specific imports for basic stuff.
Having distinct Darwin or Glibc imports seems a little crazy for these examples. When you code in c, libc is just there. It has minor variations from platform to platform, but you always think of it as libc. (Even if Darwin calls it libsystem etc. Or if Microsoft's is mscvrt and it kind of sucks.) It would be more reasonable to call it libc. (If I run on BSD do I still call it "glibc" with no actual GNU present? And if the arc4random APIs present in libc there look a lot like Darwin's because they actually share code? Maybe they have not considered porting to non-linux?)

Basically they set a portability boundary in the wrong place.

But for context, the previous sentence on that page is: “You can also import any available system modules, such as Darwin on macOS and Glibc on Linux”

The random number examples aren’t saying that’s the right way to generate random numbers in a platform-independent way, it is specifically demonstrating how to import system libraries on your local platform.

Swift 4.2 (2018) introduced a cross platform random number API.

    (0..<10).randomElement()
Yet they didn't bother to update the example on the introduction to Swift.

There are plenty of other examples I can look for, like file handling.

File handling can be done using Foundation, which I believe has API parity between Darwin and Linux at least.

I think the point of the example was to demonstrate importing platform-specific modules, not random number generation per se. But you're right, it should probably be updated to do something else.

>Yet they didn't bother to update the example on the introduction to Swift.

There are widely popular FOSS languages with much much less documentation...

Such as?
Dude you’re literally illustrating Swifts strength here. The whole point is to have a safe easy to use language that reuses existing system libraries.
Any mainstream programming language can do that.
Not many use an actual c/c++ compiler (clang) to generate language native calling convention wrappers for calling into C/ObjC code (not sure how well c++ interop works these days).
Few as elegant, as safe, or as performant combined...
Delphi, D, .NET, Eiffel, Ada, Rust, Nim.

And lets not put Swift and performance on the same sentence, they still need to catch up a bit.

https://github.com/ixy-languages/ixy-languages

for what it is worth: a few days ago I installed the latest Swift and TensorFlow in Swift on both my little MacBook and my Linux laptop (1070 GPU, i7, fast laptop).

I had to manually set LD_LOAD_PATH on macOS, but then everything worked on macOS and Linux.

Maybe, although they did just hire Dave Abrahams, who was on the Swift Standard Library team for years and seems like an excellent hire:

https://en.m.wikipedia.org/wiki/David_Abrahams_(computer_pro...

sadly i agree with you. initially i was really excited about S4TF because swift is a fantastic language and it would be a fantastic replacement for python as the defacto ML language. but then i realized tensorflow is much worse than pytorch and the S4TF team was too small to build anything substantive enough to win market share.