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.
Swift for TensorFlow Shuts Down
211–220 of 432 posts
Re: Swift for TensorFlow Shuts Down
#212Earlier quoted context omitted.
Source? Curious to read that :D
Here you are: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...
Re: Swift for TensorFlow Shuts Down
#213Earlier 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?
Re: Swift for TensorFlow Shuts Down
#214In 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
#215BTW, the Haskell bindings for TensorFlow have been actively maintained for years. The latest update was 3 days ago.
Re: Swift for TensorFlow Shuts Down
#216Earlier 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.
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
#217How is swift for stuff beyond applications for the apple ecosystem?
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
#218Earlier 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?
Re: Swift for TensorFlow Shuts Down
#219Swift 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…
Re: Swift for TensorFlow Shuts Down
#220Earlier 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 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.