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

Why Swift for TensorFlow?

github.com

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Why Swift for TensorFlow?

#61

Post by phillipcarter »

plg wrote: post #58
3jckd wrote: post #29

It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…

> why on Earth would they pick Swift Because of iOS?

iOS isn't really relevant for this. You would certainly deploy a model into an app, but that is likely to be using ONNX: https://medium.com/@alexiscreuzot/building-a-neural-style-tr...

Re: Why Swift for TensorFlow?

#62

Post by xkgt »

coder543 wrote: post #21
criddell wrote: post #20

Earlier quoted context omitted.

From the article: We believe that Rust supports all the ingredients necessary to implement the techniques in this paper: it has a strong static side, and its traits system supports zero-cost abstractions which can be provably eliminated by the compiler. It has a great pointer aliasing model, a suitable mid-level IR, a vibrant and engaging community, and a great open language evolution process. A concern with using Ru…

As I pointed out in two lengthy comments on day one[1][2], that reasoning is nonsense. If Chris wants to use the language he created in this new endeavor for machine learning simply because he made it , that's totally fine and completely his prerogative, but he should just say so, rather than trying (and failing) to convince people that other languages aren't better suited for this task. From my point of view, a weak…

It seems likely that the justification is retrofitted and team's familiarity with Swift was the bigger driver. I am surprised they didn't find Scala to be a good fit given that it has already been used with great success in Spark which I presume has similar technical requirements. Anyone can throw light on the short explanation below? Does it really apply to Scala?

"Java / C# / Scala (and other OOP languages with pervasive dynamic dispatch): These languages share most of the static analysis problems as Python: their primary abstraction features (classes and interfaces) are built on highly dynamic constructs, which means that static analysis of Tensor operations depends on "best effort" techniques like alias analysis and class hierarchy analysis. Further, because they are pervasively reference-based, it is difficult to reliably disambiguate pointer aliases."

Re: Why Swift for TensorFlow?

#63

Post by cageface »

saagarjha wrote: post #59
cageface wrote: post #51

Earlier quoted context omitted.

Swift is a nice language but its reliance on reference counting means you have to work a lot harder to avoid retain cycles than you do in a garbage collected language. That might have been the right choice for Apple’s uses of Swift where GC pauses affect the user experience but for most other use cases it’s too much of a cognitive burden IMO.

Personally, I find that this only really comes up rarely. Most of the time strong references are fine.

My iOS code is loaded with weak/strong ref handling logic. It comes up all the time when using closures in UIKit.

Re: Why Swift for TensorFlow?

#64

Post by stephencanon »

igotsideas wrote: post #57
stephencanon wrote: post #15

Earlier quoted context omitted.

FWIW, you can install Xcode 10.1 on High Sierra, and use the Swift.org 5.0 toolchain ( https://swift.org/download/#snapshots ) or build swift from source. You can't ship App Store apps this way, but it works great for experiments.

My machine is too old to upgrade to High Sierra.

https://support.apple.com/kb/SP765?locale=en_US

> MacBook Pro (Mid 2010 or newer)

So your 2011 should be supported. If it's actually an older machine, compiling from source is an option, if slightly inconvenient.

Re: Why Swift for TensorFlow?

#65

Post by saagarjha »

cageface wrote: post #63
saagarjha wrote: post #59

Earlier quoted context omitted.

Personally, I find that this only really comes up rarely. Most of the time strong references are fine.

My iOS code is loaded with weak/strong ref handling logic. It comes up all the time when using closures in UIKit.

UIKit is kind of annoying because it’s really not “idiomatic” Swift: it’s a wrapper around Objective-C (albeit, a very nice one) that happens to bring along with it a bunch of decisions that lead to having to deal with reference lifetimes.

Re: Why Swift for TensorFlow?

#66

Post by mamcx »

I vaguely know tensor flow as the most(?) popular lib of his kind, but I wonder how is the history of swift on non-apple platforms and its impact of the actual users.

Is TensorFlow "huge" in linux, windows, android? Because I also evaluate swift for my use case (https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif...) and decide instead on use rust mainly because the lack of solid support on non-apple platforms. However, after use rust for months now I still consider swift a better contender between performance/ergonomics than rust (rust is damm hard sometimes, and suddenly you could hit a trouble with above-average complications. I don't see how put this burden in a library to be used for more "regular" folks could work)

Re: Why Swift for TensorFlow?

#67

Post by celrod »

marmaduke wrote: post #34
3jckd wrote: post #29

It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…

Julia doesn't tick the "compile to .o/.h" box. As far as I can tell, the use case for AOT Julia is avoiding package compilation overhead, not delivery of standalone code objects. _edit_ seems JuliaC does support this sort of thing: https://juliacomputing.com/blog/2016/02/09/static-julia.html

If you'd like to track the latest developments:

https://github.com/JuliaLang/PackageCompiler.jl

Re: Why Swift for TensorFlow?

#68

Post by tomjakubowski »

aschampion wrote: post #35
3jckd wrote: post #29

It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…

Yeah, I don't buy the justification versus Julia because of community size either, given most of Swift's community has little to do with data science. The document even says as much, contradicting that rationale, later on. As someone who uses TF heavily, I would be much more excited about this project if they'd chosen Julia. Swift's tooling isn't great, and I already have a foot in one language with an immature data…

How is Rust-Julia interop?

Re: Why Swift for TensorFlow?

#69

Post by cageface »

saagarjha wrote: post #65
cageface wrote: post #63

Earlier quoted context omitted.

My iOS code is loaded with weak/strong ref handling logic. It comes up all the time when using closures in UIKit.

UIKit is kind of annoying because it’s really not “idiomatic” Swift: it’s a wrapper around Objective-C (albeit, a very nice one) that happens to bring along with it a bunch of decisions that lead to having to deal with reference lifetimes.

That could be. I'll admit I haven't used Swift at all outside of coding Appkit/UIKit apps.

Re: Why Swift for TensorFlow?

#70

Post by 5stospace »

I still don't understand why they would choose Swift over C#?

They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#?

I don't think Swift has any inherent objective advantages over c#.

I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on linux/mac/windows.

Post reply on HN