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

201–210 of 432 posts

Re: Swift for TensorFlow Shuts Down

#201

Post by adsharma »

dagmx wrote: post #135
adsharma wrote: post #104

Earlier quoted context omitted.

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.

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

#202

Post by skohan »

SatvikBeri wrote: post #196
ZeroCool2u wrote: post #155

Earlier quoted context omitted.

function julia_blues(bummers...) I largely agree, Julia is such a cool language and had so much potential. It definitely surprised me when they went with Swift instead, but realizing that Chris Lattner worked at Google at the time explained a lot. Unfortunately, every time I try to get into Julia, it just feels awkward coming from Python and a bit like stepping back in time. The stupidest, (stupidest in the sense tha…

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

#203

Post by adsharma »

ZeroCool2u wrote: post #155
nextos wrote: 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.…

function julia_blues(bummers...) I largely agree, Julia is such a cool language and had so much potential. It definitely surprised me when they went with Swift instead, but realizing that Chris Lattner worked at Google at the time explained a lot. Unfortunately, every time I try to get into Julia, it just feels awkward coming from Python and a bit like stepping back in time. The stupidest, (stupidest in the sense tha…

If it's just the syntax and muscle memory you are quibbling about, you can use python to write code and then transpile it to Julia. Link to github in my other comment in this article.

Re: Swift for TensorFlow Shuts Down

#204

Post by BadInformatics »

marcinzm wrote: post #150
BadInformatics wrote: post #134

Earlier quoted context omitted.

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!

Which is sort of my point. If you have to rewrite or expand significant parts of the the type system anyway is there any advantage over just doing the same work for Python? There's many other advantages of Swift over Python for ML (concurrency and performance) but I just don't see the type system as one. At least not anymore.

I mean yes, because a) there's less to change, b) you still have nice features like protocols and c) Python's type system is pretty unsound. My point was that saying ML is too complex for type systems is really a cop out, and that has been borne out by how many languages have started experimenting with more complex types for this exact purpose.

Re: Swift for TensorFlow Shuts Down

#205

Post by lostmsu »

And TensorFlow for C# is alive and kicking: https://losttech.software/gradient.html

I guess this is sort of an ad.

Swift was a weird choice for statically typed TensorFlow, being only popular on the platform, that does not have GPU/TPU support in TensorFlow, which is, basically, a requirement for any serious work. The fact, that they had to fork the compiler did not help either.

TensorFlow for C# is much like TensorFlow for Swift. There's a statically typed binding to the core types with the rest of the TensorFlow API available through an open source Python.NET project [1]. Unlike Swift version though, that second part is also mostly statically typed, so you can get IDE autocompletion hints. Also, .NET runtime has native support for dynamic languages.

Like with Swift for TensorFlow, we ported all recent interesting neural network architectures (and maybe even more): Transformers (GPT-2) [2], CNNs (YOLOv4) [3], Q-learning (e.g. RL, actor-critic) [4], and even some cool ones, that have lots of unexplored potential like Siren [5] (this one uses sin/cos as activation functions).

Although we have not worked on automatic differentiation yet, unlike Swift, it will not need compiler support. .NET (and Java) can inspect and generate code at runtime, so autodiff can be implemented in a library.

We also have integration with Unity ML Agents for training robotic agents [4].

[1] https://github.com/pythonnet/pythonnet/

[2] https://github.com/losttech/Gradient-Samples/tree/master/GPT...

[3] https://github.com/losttech/YOLOv4

[4] https://github.com/losttech/Gradient-Samples/tree/master/RL-...

[5] https://github.com/losttech/Siren https://vsitzmann.github.io/siren/

Re: Swift for TensorFlow Shuts Down

#206

Post by lostmsu »

cs702 wrote: 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.

Re: Swift for TensorFlow Shuts Down

#207

Post by mcast »

flipgimble wrote: post #195

Another sad lesson why no open source developer should trust Google with their time and effort. Swift is a gem of a language with an unfortunately Apple-centric ecosystem, but at least you know Apple won't abandon the effort.

Let's be honest, Google still contributes more heavily to OSS, whitepapers, and security research than Apple does.

Re: Swift for TensorFlow Shuts Down

#209

Post by dwaite »

ChrisMarshallNY wrote: post #64
Hamuko wrote: post #27

Earlier quoted context omitted.

> a very niche market of 100% native mobile development I mean, it also works for native desktop development. And is there really an issue with that? Objective-C basically had no reason to exist beyond iOS/Mac programming and at least now we don't have god damn [myString stringByAppendingString:@"another string"].

I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both). I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems. That said, I have not done system programming for a…

I suspect we will hit an inflection point where Objc is bridged to swift code rather than the other way around - no reason to let Swift be the one taking the interoperability hit.

There are already controls in Big Sur and iOS 14 (Color Picker) which are SwiftUI and bridged to UIKit/AppKit.

Re: Swift for TensorFlow Shuts Down

#210

Post by eigenspace »

wsmoses wrote: post #193
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…

The name of the LLVM AD tool is actually Enzyme [ http://enzyme.mit.edu/ ] (Zygote is a Julia tool)

I think they probably mistook julia's IR from LLVMs IR
Post reply on HN