Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

111–120 of 432 posts

Re: Swift for TensorFlow Shuts Down

#111
post #99
post #82

Earlier quoted context omitted.

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

> there's every indication that all new Apple frameworks are being written in Swift There's no such indication. "The number of binaries using Objective-C is still growing with each iOS release." https://blog.timac.org/2020/1019-evolution-of-the-programmin...

The number of binaries of all languages in iOS (except C) increases year over year, so that doesn't really mean anything. It's more telling that the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year.

Re: Swift for TensorFlow Shuts Down

#112
post #100

It seems this was written on the wall once Chris Lattner left the project. It's a shame since this could have been a real breakthrough in machine learning combining performance and ease. But the success of JAX means Google probably doesn't feel the investment is worth it.

I mean, I'm fairly certain that this project is the reason Chris Lattner joined Google; it was somehow in his contract somewhere. He just found a way to shoehorn himself in there and make sure that the language that he designed (Swift) is used for something more than just iOS apps. Nothing against him at all, I think most folks would want to push their brainchild as far as they can, but that's just what it looks like from the outside.

Since ML has been a large rage for the last few years, and TensorFlow is one of the most popular frameworks that ML engineers use (although I use and prefer PyTorch) it seemed like the "perfect storm" for Swift to break out of the iOS mold.

But it was clear to me (and many of my peers) that while this was an interesting project, the need for it is really low, and that nobody is going to throw away years of experience with libraries like TensorFlow and PyTorch (via Python) in the trash just so we can use Swift, which for me isn't really that crazy of a language as all the hype makes it out to be, and I'm sure the same is true for many ML devs and researchers alike.

Re: Swift for TensorFlow Shuts Down

#113
post #99

Earlier quoted context omitted.

> there's every indication that all new Apple frameworks are being written in Swift There's no such indication. "The number of binaries using Objective-C is still growing with each iOS release." https://blog.timac.org/2020/1019-evolution-of-the-programmin...

The number of binaries of all languages in iOS (except C) increases year over year, so that doesn't really mean anything. It's more telling that the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year.

> The number of binaries of _all languages_ in iOS increases year over year

This is not true either. "the number of binaries written entirely in C is now stagnating"

> the number of Swift binaries in proportion to the number of Objective-C binaries is increasing year over year

This is true. But it's a much weaker claim than the one I was replying to.

In other words, the reports of Objective-C's death have been greatly exaggerated. ;-)

Re: Swift for TensorFlow Shuts Down

#114
post #91
post #26

It's a shame. I had high hopes at the beginning that S4TF - and the investment in Swift from Google - would help Swift break out of the iOS ghetto and cement it as a mainstream language. Swift's a delightful language to use. It has a lot of the nice things about Rust's type system, but is a heck of a lot easier to use at the expense of a bit of performance. For a lot of use cases, I think this is a great value propos…

I agree and am also disappointed. On the other hand, I really don't miss Swift outside of iOS because of Rust and Kotlin. I wonder if Kotlin is too far from "arms length" from the low level details in your mind? Because other than that, I actually prefer the language over Swift, generally.

Agreed. Thomas Nield has some interesting talks and libraries available for doing data science work in Kotlin.

Re: Swift for TensorFlow Shuts Down

#115

Earlier quoted context omitted.

> I prefer having a Python monoculture for AI to be able to mix and match different algorithms Given how divergent the current crop of ML frameworks are, is this really a realistic expectation? Having played around with Julia and Flux for ML, I find I have to do just as much rewriting when translating e.g. TF -> Flux as TF -> PyTorch. You get some limited mixing and matching with Caffe2 Torch and TF JAX, but that bre…

I agree that there is poor interoperability between the different DL / auto-diff frameworks in python. But I suspect the GP is referring also to things like scikit learn, numpy, plotting tools, PIL, opencv, pandas, etc. that make up the python ecosystem. I know that alternatives exist in other languages, but I don't know of an overall ecosystem that is as mature and interoperable as in python.

Then you haven't looked at Julia's ecosystem.

It may not be quite as mature, but it's getting there quickly.

It's also far more interoperable because of Julia's multiple dispatch and abstract types.

For example, the https://github.com/alan-turing-institute/MLJ.jl ML framework (sklearn on steroids), works with any table object that implements the Tables.jl interface out of the box, not just with dataframes.

That's just one example.

Re: Swift for TensorFlow Shuts Down

#117

Earlier quoted context omitted.

While I love using Julia for many things, I prefer having a Python monoculture for AI to be able to mix and match different algorithms. At the end the engine that compiles the mathematical expression to hardware is what matters, and I don't think that LLVM IR that uses is the best IR for the optimizations.

> I prefer having a Python monoculture for AI to be able to mix and match different algorithms. I do not. Unfortunately, high performance and python do not go hand in hand. Yes, I know the heavy lifting is done by C/C++/Rust/Cuda/Blas/Numba and so on, but, when you run simulations for millions of steps, you end up with billions of python function calls. Afaik only Jax actually performs any optimizations because it co…

I'm not sure I understand what your getting at. If Python's performance in the ML space is not sufficient, then the community would have quickly moved on from it and built something better.

And that something better is certainly not Julia and it's definitely not Swift.

> Yes, I know the heavy lifting is done by C/C++/Rust/Cuda/Blas/Numba and so on, but, when you run simulations for millions of steps, you end up with billions of python function calls.

For ML purposes, if your model isn't running on the GPU, it doesn't matter if you're using Swift, Rust, or whatever, your stuff is gonna be slow. Like it or not, Python is one of the best glue languages out there, and the reason why libraries like TensorFlow and Torch are not used in their native languages (C++) [0] is because they're significantly simpler to use in Python and the performance overhead is usually one function call (e.g run_inference(...)) and not billions.

If you find yourself writing a simulation, and you need to optimize away billions of function calls, you can use the C++ API provided by TensorFlow.

[0] https://www.tensorflow.org/api_docs/cc

Re: Swift for TensorFlow Shuts Down

#118
post #99
post #82

Earlier quoted context omitted.

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

> there's every indication that all new Apple frameworks are being written in Swift There's no such indication. "The number of binaries using Objective-C is still growing with each iOS release." https://blog.timac.org/2020/1019-evolution-of-the-programmin...

If you look closely at how that data was collected, what it's actually measuring is whether a binary links against the ObjC runtime library, which will be the case if a binary transitively depends on any ObjC framework, so even if all new frameworks and executables were written in Swift, we would still expect to see the number presented in that post to continue to grow until most or all of the important frameworks using ObjC are rewritten entirely in Swift. I don't think this data is sufficient to say one way or the other to what degree that is occurring.

Re: Swift for TensorFlow Shuts Down

#119
S4TF lost out, not to Python, but to Python's AI/ML ecosystem -- people, projects, libraries, frameworks.

Despite its many shortcomings, Python has become the lingua franca of AI and ML, to the point that whenever I come across a newly published AI or ML paper that I find interesting, I expect to be able to find code implementing it in Python.

For example, yesterday I saw a post on HN about approximating self-attention matrices in transformers, which have O(n²) computational cost, with a seemingly clever approach that has O(n) computational cost: https://news.ycombinator.com/item?id=26105455 . "Huh, that looks interesting," I thought, "let me see if I can find some code." Three clicks later, I found myself at https://github.com/mlpen/Nystromformer -- the official implementation... in Python. A few moments later, I was playing with this thingamajiggy. No other language comes close to having this kind of ecosystem in AI and ML.

Julia still has a shot at becoming a viable alternative to Python, especially if the Julia developers can shorten the "time to first interactive plot" to make it as fast as Python's, but they face an uphill battle against such an entrenched ecosystem.

Re: Swift for TensorFlow Shuts Down

#120

Earlier quoted context omitted.

Have an effect at runtime.

What does this mean? Runtime is the only time that Python's existing type system has an effect.

GP was referring to type hints and how they don't provide any runtime validation. There are libraries like Pydantic that let you do some, but nothing built into the language runtime IIRC.
Post reply on HN