Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

211–220 of 432 posts

Re: Swift for TensorFlow Shuts Down

#211
post #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-attenti…

Nystromformer attention layer is actually pretty simple. You can reimplement it in a few minutes.

Sure, but isn't it nice that you don't even have to read the paper to play with the full model, to see if the claims hold up, using the same Python tools you and everyone else uses?

Re: Swift for TensorFlow Shuts Down

#212
post #77

Earlier quoted context omitted.

Source? Curious to read that :D

Here you are: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...

I always figured they would have chosen rust if it weren't for Lattner's sway (real or perceived) in the Swift compiler development community. One underestimated advantage of rust over swift in my view is that it has interested practitioners across a much more diverse range of problems spaces. I think it was always going to be hard to convince people to use a language for for ML when most of its practitioners are solely mobile developers. But people already used rust for lots of different kinds of data processing heavy use cases.

Re: Swift for TensorFlow Shuts Down

#213
post #135

Earlier quoted context omitted.

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

The lack of algebraic data types is what python gets criticisms about. That situation is improving, but I would have preferred match to be an expression rather than a statement. What else is missing in the python3 type system?

Actual static typing and forced type checking.

Re: Swift for TensorFlow Shuts Down

#214
This is sad for the project itself, but I predict that the coming programming competition will be Rust vs. Go, not Swift -- as Swift was always a distant third among the "new" languages. And of course the more mature languages will continue to be popular and widely used for decades.

In my opinion, Rust will end up winning this contest, but others have perfectly good arguments against that view. Unfortunately for server-side Swift and the many good people who've worked on it, there seems little chance for it, in TensorFlow or other usecases.

Re: Swift for TensorFlow Shuts Down

#215
I am disappointed, but so it goes. I started writing a Swift AI book a while back and I had planned on abut 20% of the book would be on S4TF. I still have lots of other material, but obviously I am not going to include S4TF material.

BTW, the Haskell bindings for TensorFlow have been actively maintained for years. The latest update was 3 days ago.

Re: Swift for TensorFlow Shuts Down

#216
post #60

Earlier quoted context omitted.

I love all languages in the ML/Haskell tradition, but I think Julia would have been a better fit because it's dynamic yet efficient, and because it has a really decent probability/statistics/ML ecosystem already. Long term, I think it's the best replacement we have for Python in the ML world. Python has exceptional libraries but, as a language, it's a bit dated on several fronts. This has an impact on library design.…

Julia gets compared a lot to Python but truthfully it strikes me as more like a replacement for FORTRAN, MATLAB, and R. The ergonomics of the language seem good but documentation is poor and as a community it's narrowly scoped into the ML/numerical processing world. If all you do is ML/numerical processing, against data that's already been cleaned up, I bet it's really great tho.

The comparison is natural because Python is a general purpose language which happens to be used for data science, the same can be said about Julia. The others languages mentioned are not really that great for general purpose programming.

But I agree with you that in the short term it is a replacement for Fortran, Matlab and R. But a new language has to start somewhere. Attacking the niche filled by these language is natural as these are old, dated and ripe for disruption. The key is to gain some critical momentum and user base. That will carry the language to other domains.

Re: Swift for TensorFlow Shuts Down

#217

How is swift for stuff beyond applications for the apple ecosystem?

I was using this project for my stock trading bot.

Way nicer to use Swift than python for this, and I have rewritten this bot several times in different languages + frameworks (objc php java python swift tf1.0 theano keras s4tf) since 2012.

Doing authentication for brokerage apis + correctness from pulling from the db is easier to get right in Swift than python bc of the static typing + grand central dispatch for parallel queries.

It is also way more productive for me to have the compiler catch issues at the beginning instead of 6 hours into a data generation job where the python interpreter sees a None for something I didn't think of.

Re: Swift for TensorFlow Shuts Down

#218
post #202

Earlier quoted context omitted.

I love Julia in general, but yeah, I hate `end`. Re: 0-indexing vs 1-indexing. If you use 0-indexing, you turn off a lot of non-engineering scientific programmers. My personal experience is that 0-indexing is better for more engineering applications, while 1-indexing is better for math. I'm a weirdo in that I don't seem to mind either one though.

Is there an example of where 1 is better for math, or is it just a familiarity thing?

As a trivial example, if you want to get the sum of the first n numbers, that's `sum(range(n+1))` in Python. Or if you want to get all the prime numbers <= n, find the triangular numbers, etc. In general you end up with a lot of `n+1`s and it's easy to lose track or miss some, and end up with a silent, non-crashing error that produces the wrong result because you're accidentally leaving out the last element of your input.

Re: Swift for TensorFlow Shuts Down

#219
post #56

Swift for TensorFlow was a nice idea on paper, but you need more than ideas to push a project forward. You need people who actually want to use your product. For all the comments on HN about how great Swift was, there were hundreds if not thousands of ML engineer and research scientist who did not know it existed and frankly did not really care about it either. Swift for Tensorflow was not addressing the issues of ML…

It's interesting to compare Swift to Julia here – Julia had a base of people who absolutely loved it from the 0.2 days, and has managed to draw many users from Python/Matlab/R. There are many reasons for that, but overall Julia had something that really appealed to scientists: syntax they liked + competitive-with-C performance. In contrast, S4TF's target audience seems to have been Swift developers, and they didn't r…

We see this all the time right, the next big ML company is going to come from some scrappy startup with a precise focus on what to do (either because they're geniuses or because they're just the lucky idiot amongst 10,000 ML startups), not from some behemoth that decides "we'll eat that for breakfast". Swift4ML suffers from the fact that Swift exists. To make S4ML work you need to abandon atleast some of the things that makes Swift Swift.

Re: Swift for TensorFlow Shuts Down

#220
post #60

Earlier quoted context omitted.

I love all languages in the ML/Haskell tradition, but I think Julia would have been a better fit because it's dynamic yet efficient, and because it has a really decent probability/statistics/ML ecosystem already. Long term, I think it's the best replacement we have for Python in the ML world. Python has exceptional libraries but, as a language, it's a bit dated on several fronts. This has an impact on library design.…

> Python has exceptional libraries but, as a language, it's a bit dated on several fronts. I've been using Python for ML for the last 3 years and I've never felt this way. It might be that I'm not all about the hip new languages, but I don't really see the benefit of making Python more ML/Haskell-ish. The ML use case for Python is roughly as follows: you design, train, and evaluate models. Then, if something is decen…

> There's nothing stopping you from composing things in Python.

There is, and you pointed it out yourself:

> I don't see why you would compose a TensorFlow model with a PyTorch model without incurring tons of overhead in your application around gluing these two things.

This is where Julia is profoundly different. Reusing stuff from different libraries is trivial compared to Python. You could take an activation function made for one libraries use it without any modification or wrapping in another ML library.

These is where Julia will win long term. If you look at the ML libraries in Julia they are tiny. The Python side of things require gargantuan effort because things are not composable. The wheel is reinvented over and over again.

Post reply on HN