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

41–50 of 432 posts

Re: Swift for TensorFlow Shuts Down

#41

Post by Zababa »

bsaul wrote: post #6

Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development. I love this language, but i'm eager to see it handled by a proper found…

> I have the feeling swift never really worked in the server side

IBM dropped Kitura more than a year ago [1]. There's Vapor [2] which seems popular, but I don't know how much.

[1]: https://forums.swift.org/t/december-12th-2019/31735

[2]: https://github.com/vapor/vapor

Re: Swift for TensorFlow Shuts Down

#43

Post by [deleted] »

SatvikBeri wrote: post #25
MrPowers wrote: post #18

Earlier quoted context omitted.

It seemed like Swift looked like a promising language for data science a few years ago. I'm not familiar with Swift. Can anyone provide additional context as to why the language seemed promising for data?

I disagree with the pitch, but the pitch I heard when this was announced was: * Swift lets you write code that's as concise as Python while still being fast, and therefore allows you to get away from the problem of having to write ML code in multiple languages (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.) * That the lack of static typing is a major pain point in Python…

[deleted]

Re: Swift for TensorFlow Shuts Down

#44

Post by saagarjha »

echelon wrote: post #39
saagarjha wrote: post #35

Earlier quoted context omitted.

LLVM? WebKit?

WebKit got forked into Blink, which is no longer under Apple leadership. Brave, Chromium, and the other major KHTML-derived browsers adopted this. I can think of dozens of examples from Microsoft and Google, which are more "outside ecosystem" inclusive as a means of gaining mindshare. TypeScript, Golang, Visual Studio Code, protobuf, gRPC, ... Other companies think of the things living outside their moat more flexibl…

In what sense? 90% of the commits come from Apple and they drive most of the technical direction…

Re: Swift for TensorFlow Shuts Down

#45

Post by grey-area »

bsaul wrote: post #6

Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development. I love this language, but i'm eager to see it handled by a proper found…

Don't worry, in a few years Apple will rewrite all their SDKs again in a different language.

The churn may not be a deliberate strategy but it is certainly very effective in locking developers in.

Re: Swift for TensorFlow Shuts Down

#46

Post by coolspot »

saagarjha wrote: post #35
echelon wrote: post #31

Earlier quoted context omitted.

Swift never had a good outside-Apple story. Apple isn't the sort of company that jumps at opening up its platform or tooling for non-Apple uses. There's nothing wrong with this. Swift can be the best language for the Apple platform and find lots of success in that.

LLVM? WebKit?

WebKit started as KDE’s KHTML/KJS and LLVM started as a research project at Univeristy of Illinois.

Apple took the code and extended it, they had little choice for the source code license.

https://en.wikipedia.org/wiki/Webkit

https://en.wikipedia.org/wiki/LLVM

Re: Swift for TensorFlow Shuts Down

#47

Post by favorited »

ipsum2 wrote: post #22

No surprises there. There were maybe a total of 5 people excited about adding automatic differentiation to Swift. Too bad they didn't try improving Julia instead.

> adding automatic differentiation to Swift

That work is still happening (as noted in the link). One of the primary engineers who was working on it at Google works at Apple now.

Re: Swift for TensorFlow Shuts Down

#48

Post by coolspot »

favorited wrote: post #42
tsegratis wrote: post #38

Earlier quoted context omitted.

Neither originated with Apple, though I agree Apple did a lot to push them and make them what they are

OK, Clang then.

It’s started in the Univerity of Illinois, and still under their source code license.

Re: Swift for TensorFlow Shuts Down

#49

Post by PartiallyTyped »

xiphias2 wrote: post #40
ipsum2 wrote: post #22

No surprises there. There were maybe a total of 5 people excited about adding automatic differentiation to Swift. Too bad they didn't try improving Julia instead.

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 constructs an analytical gradient. Zygote seems to be able to that and more on the LLVM IR level which, I think should enable more optimizations.

Re: Swift for TensorFlow Shuts Down

#50

Post by wendyshu »

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…

What are some ways in which Python's type system should improve?
Post reply on HN