Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

Post reply on HN
Print view View original

131–140 of 432 posts

Re: Swift for TensorFlow Shuts Down

#131

Post by _qulr »

copascetic wrote: post #118
_qulr wrote: 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...

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 us…

Fair criticism. I'm not sure why the author didn't try to detect the use of objc_msg functions, for example. So the ObjC binaries may be overcounted a bit.

Still, the test for Swift binaries seems accurate, and if you look at iOS 13.1 vs 14.0, for example, according to the chart there was an increase of 157 Swift binaries and 446 Objective-C binaries. If we assume there are 157 "false positives" in the ObjC binaries, that's still an increase of 289 ObjC binaries that don't use Swift at all.

Re: Swift for TensorFlow Shuts Down

#132

Post by amkkma »

swagonomixxx wrote: post #117
PartiallyTyped wrote: post #49

Earlier quoted context omitted.

> 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…

>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.

I prefer to just use Julia and get that for free. Also can write custom cuda kernels in pure Julia. And differentiate through arbitrary julia code, compose libraries that know nothing about each other etc

Re: Swift for TensorFlow Shuts Down

#134

Post by BadInformatics »

marcinzm wrote: post #68
skohan wrote: post #36

Earlier quoted context omitted.

- There simply being no good reason for Python users to ever move to Swift. There is no big painpoint being solved for the broad ML user community As a swift and python user, I would have been really happy to be able to use swift for ML applications. Having a half way decent type system solves so many problems. But while I can see that from my vantage point, I know for a vast majority of the ML community python is "g…

I'm not sure if the Swift type system is half way decent in terms of machine learning applications. At least not without a lot of work. The data tends to be in specialized in-memory formats that tend to be opaque to the type system. The actual matrix operations involve dimension parameters that are likewise opaque to most type systems. So you still need to run code for the actual tensor graph compilation to validate…

In addition to what the sibling said, a big part of the S4TF project was proposing changes to Swift's type system. I'd also point out that there are not one, not two, but three type checkers looking into tensor typing for Python. What's more, Guido is on that committee!

Re: Swift for TensorFlow Shuts Down

#135

Post by dagmx »

adsharma wrote: post #104
skohan wrote: 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…

Python type system is improving. Another point in this ease of use vs type safety spectrum is python -> type safe language static compilation. I don't know which one is the best. So I've been experimenting with several. https://github.com/adsharma/py2many

Is the Python type system improving or is it the type annotation system that's improving? Big difference between the two.

Re: Swift for TensorFlow Shuts Down

#136

Post by swagonomixxx »

skohan wrote: post #36
high_derivative wrote: post #16

S4TF from my (external) perspective was always more a (very cool!) programming language research project than anything else, at least since Lattner left. I would personally assume the shutdown was due to a combination of reasons: - There simply being no good reason for Python users to ever move to Swift. There is no big painpoint being solved for the broad ML user community - Organisational momentum lost with Lattner…

- There simply being no good reason for Python users to ever move to Swift. There is no big painpoint being solved for the broad ML user community As a swift and python user, I would have been really happy to be able to use swift for ML applications. Having a half way decent type system solves so many problems. But while I can see that from my vantage point, I know for a vast majority of the ML community python is "g…

> Having a half way decent type system solves so many problems

What problems does it solve for you? When building ML applications I mean. Because that's what S4TF was supposed to be.

ML researchers produce models that are used by ML applications for a particular purpose. The code to train the model _could_ be statically typed, sure, but I really don't see what the improvement would be. It would be more verbose, less readable, have significantly more noise. Just try reading some TensorFlow C++ code equivalents of their Python API.

From the "WhySwiftForTensorFlow.md" document (https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...):

.. static types: * can catch bugs at compile time instead of runtime. People get very frustrated when a silly type error brings down a long training run hours into it. * directly improve tooling experience like code completion/intellisense, jump to definition, etc. * make it easy to know what operations are Tensor operations.

> can catch bugs at compile time instead of runtime.

OK, but what bugs? For most use cases of TensorFlow that I've seen, if there is a type error somewhere, you will catch it long before it hits production, and if you only catch it 100hr into training, your training code is either non-deterministic or there's some other issue that is not type related. Unless we're talking about dependent types a-la Idris, I don't see how Swift's type system can help catch these kinds of bugs.

> directly improve tooling experience like code completion/intellisense

Sure, but type-hints provide the same improved experience with language servers like PyLance [0]. Not a reason to jump to a new language.

> make it easy to know what operations are Tensor operations.

Easy. Anything that starts with "tf." is a tensor operation.

Yes, I'm being a bit trite, but I was never convinced by the premise of S4TF, because I've never heard an ML researcher or engineer say "static typing will fix my problems".

[0]: https://devblogs.microsoft.com/python/announcing-pylance-fas...

Re: Swift for TensorFlow Shuts Down

#137

Post by laurencerowe »

simias wrote: post #70
superbcarrot wrote: post #57

Earlier quoted context omitted.

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

I wish JS had ignored type annotations built into the language so that TypeScript code could run directly without a transpilation step.

Re: Swift for TensorFlow Shuts Down

#138

Post by swagonomixxx »

akmittal wrote: post #28

Swift for tensorflow never made any sense. I remember only reason it started was one main developer on team liked swift. Tensorflow for nodejs makes much more sense, node community is lit bigger and not sponsored by big corp.

Well, there is already Tensorflow.js [0].

[0]: https://www.tensorflow.org/js.

Re: Swift for TensorFlow Shuts Down

#139

Post by bartvk »

moocowtruck wrote: post #125
simonbarker87 wrote: post #76

Earlier quoted context omitted.

It doesn’t solve the issue of JS but NestJS feels like a more robust way to make a server in JS - and the docs are great.

nestjs is an atrocity that should not have been wrought upon the js/ts community..

Please check the guidelines via the link at the bottom. What you're doing is called shallow dismissal.

Re: Swift for TensorFlow Shuts Down

#140

Post by iujjkfjdkkdkf »

amkkma wrote: post #115
iujjkfjdkkdkf wrote: post #107

Earlier quoted context omitted.

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 jus…

To be clear, I'm a big Julia fan and would love to be able to move to Flux.jl (I have not looked at the framework you linked but will now). But Julia is still overall more fragmented, sparsely supported, and not as easy to work with as python for ML projects. If I have a budget to work against, I cant justify trying to deal with the rough edges in Julia.
Post reply on HN