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

381–390 of 432 posts

Re: Swift for TensorFlow Shuts Down

#381

Post by mark_l_watson »

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…

I think your pain points with Julia are real, but they don’t bother me too much. I mostly use Lisp languages, enjoy but am not so good with Haskell, so I am very flexible in syntax. I shared the dislike for 1 based indexing, but when I recently started evaluating Wolfram/One and Language, my limited experience with Julia and Octave made Wolfram’s use of 1 based indexing OK.

I love experimenting with programming languages but I don’t like recommending languages just as I don’t like recommending movies: I figure that everyone has their own tastes, and that is a good thing.

Re: Swift for TensorFlow Shuts Down

#382

Post by sanderjd »

johnnycerberus wrote: post #378
sanderjd wrote: post #368

Earlier quoted context omitted.

That is true, and certainly relevant, but I believe it is also true that Scala does not meet the criteria for what that were trying to do, because it is not easy (perhaps not possible) to do the kind of static analysis necessary to achieve their goals. For a generic "what language with a good type system should we use with ML?" project, I would totally agree with you that Scala is an obvious choice. But this project…

I really don't see how Scala is not fit for this. Swift for Tensorflow was mainly revolving around the Differentiable protocol. There is a paper published in 2019 from Purdue University where they show how AD can be combined with multi-stage programming in Scala. [1] DeepLearning.scala that does compile-time reverse AD. [2] Compute.scala for operator fusion at runtime (JITifying) [3] Here [4] is a Pre-SIP to add reif…

Neat! This may have not been well known when they kicked off the project and wrote their reasoning. Here is what they had to say about Scala at the time of the document linked up-thread[0]:

"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."

If they were wrong about that, or if the state of the art has progressed in the meantime, that's great! You may well be right that Scala would be a good / the best choice if they started the project today.

[0]: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...

Re: Swift for TensorFlow Shuts Down

#383

Post by dagmx »

dragonwriter wrote: post #360
dagmx wrote: 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.

> Is the Python type system improving or is it the type annotation system that's improving? Both. (The type annotation system is deeply tied to the type system, since the latter is what is statically verified, but there are improvements both in what can be checked—the type system—and how that is expressed/annotated.)

Do you have examples of how the type system (not annotations) have been improved?

Re: Swift for TensorFlow Shuts Down

#384

Post by O_H_E »

socialdemocrat wrote: post #240

Back when I was doing a lot of Swift programming, this seemed like such a great idea. Since then I moved on to Julia. And when I looked at the ML code for Swift and compared it to Julia, I was thinking "How on earth could anyone think this was ever a good idea?" Doing machine learning stuff in Julia is simply much more user friendly than doing the same in Swift. Swift is nice for iOS development, but I think in data…

Just a reminder that latency has been aggressively worked on in 1.5 and 1.6 releases. Example graph. Https://i.redd.it/ik4uymvb28k51.png

Re: Swift for TensorFlow Shuts Down

#385

Post by The_rationalist »

dd82 wrote: post #372
The_rationalist wrote: post #291

Earlier quoted context omitted.

https://www.tensorflow.org/guide/tf_numpy

yes, and if you go to that link, you can see its experimental, for TF 2.4 _and_ the notebook on github was created Aug 3, 2020. So that is relatively new and most likely has a ways to go before further adoption. Its good that option exists, but doesn't seem very backwards compatible. That doesn't negate the points made in the parent.

It will mature before the Julia ecosystem mature so the value proposition of Julia is out weighted by it's lack of ecosystem. Had they transparant interoperability with Python like Kotlin is for Java, I would consider it. They could at least rewrite their vm to use the truffle framework from graalvm so that they would become interoperable with Python on graal which in a few years will mature.

Re: Swift for TensorFlow Shuts Down

#386

Post by liuliu »

The_rationalist wrote: post #375
andrekandre wrote: post #343

Earlier quoted context omitted.

> Also swift support for interfaces (protocol) is sub-par with today standards interesting, what could be added/changed to make it better?

No support for default implementation methods. No support for generics in protocol. There might be workarounds but for a newcomer, this is a red flag of reinventing a basic and universal construct (interfaces) in a sub-par one, this show a dangerous mentality from the swift vm devs, what else did they wrongfully reinvent in a sub-par way?

There is support for default implementation method in protocol for a while now.

Generics are supported through associated types.

Re: Swift for TensorFlow Shuts Down

#387

Post by mumblemumble »

pjmlp wrote: post #339
uryga wrote: post #253

Earlier quoted context omitted.

> I can't speak to why run-time checking wasn't built into the language as a default behavior tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful --- there's a bunch of libraries that do this, and they're all fundamentally limited [though i guess some of these may just be failures of imagination on my part]: - hard to check ge…

> tldr: you other get either huge overhead or need to type annotate everything like it's Java, and it'll still be pretty limited/not super useful Still using Java 8 are we?

I'm pretty sure the level of type annotation you'd get roped into doing would be about on par with what you get in Java 10: function parameter and return types, but not local variable types.

Re: Swift for TensorFlow Shuts Down

#388

Post by skohan »

kortex wrote: post #369
skohan wrote: post #173

Earlier quoted context omitted.

Language aesthetics do matter. Broadly it seems like we've accepted that "c like" syntax - including brace-delimited blocks and zero-based indexing - should be the norm for programming languages. Any language which goes in a different direction should have a very strong reason to do so, because any deviation will be an obstacle for adoption. I share your frustration with the `end` keyword - it's just needlessly verbo…

I use an ergodox keyboard with a custom Dvorak based layout. Underscore is pretty prominent, analogous to the 4 key with no modifiers. It makes a huge difference, so much so that using camelCase feels like a huge drag. Qwerty is frankly awful for programming. I encourage everybody to look into alternate layouts.

So would you seriously suggest that programming languages should be optimized for extremely rare, niche keyboards rather than the standard that ships with virtually every laptop which nearly 100% of coders will be using?

Re: Swift for TensorFlow Shuts Down

#389

Post by detaro »

skohan wrote: post #388
kortex wrote: post #369

Earlier quoted context omitted.

I use an ergodox keyboard with a custom Dvorak based layout. Underscore is pretty prominent, analogous to the 4 key with no modifiers. It makes a huge difference, so much so that using camelCase feels like a huge drag. Qwerty is frankly awful for programming. I encourage everybody to look into alternate layouts.

So would you seriously suggest that programming languages should be optimized for extremely rare, niche keyboards rather than the standard that ships with virtually every laptop which nearly 100% of coders will be using?

They are clearly not suggesting that.

Re: Swift for TensorFlow Shuts Down

#390

Post by pjmlp »

GregarianChild wrote: post #370
lmm wrote: post #355

Earlier quoted context omitted.

Swift just seemed like yet another OCaml-like language to me; there are certainly far worse languages to borrow from, but I don't see any compelling reason why I'd use it over OCaml. ARC has the same worst cases as mark/sweep GC AIUI; exiting any scope might cause an arbitrarily large amount of cleanup work in the general case, and it doesn't solve the memory fragmentation problem which is the main reason you still n…

I agree from a technical POV, but there is a social reason (network effect): Swift has Apple-backing, OCaml is not currently supported by any of the big, influential software companies. OCaml's main backer now is Jane Street who do a lot, but is too small, and Facebook's support (via ReasonML) is too half-hearted to be compelling. As a former OCaml programmer, I would not currently bank a career or startup on OCaml.…

> ...F#/C# being JIT'ed...

Nope, NGEN exists since .NET 1.0, .NET Native since Windows 8, Mono aot since ages, and then there are the third party tooling like IL2CPP.

Post reply on HN