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

271–280 of 432 posts

Re: Swift for TensorFlow Shuts Down

#271

Post by skohan »

socialdemocrat wrote: post #232
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 would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for othe…

Typing braces is basically a gesture. You hold the shift key with left pinky, and roll right ring finger pinky over open and close brace, then tap back arrow and return to get you inside the block. End is three distinct key presses.

Also braces have a nice symmetry, which is also convenient for parsers and tooling to count opens and closes.

I also think "end" is just more visually noisy. Braces are a symbol, so it's easy to filter them out when you're looking at code, but a trail of "end"s takes up more real-estate than is semantically justified.

Re: Swift for TensorFlow Shuts Down

#272

Post by skohan »

eigenspace wrote: post #252
socialdemocrat wrote: post #232

Earlier quoted context omitted.

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for othe…

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of in static languages.

What's the difference to you for using {} vs ?

Re: Swift for TensorFlow Shuts Down

#273

Post by cs702 »

lostmsu wrote: post #258
cs702 wrote: post #211

Earlier quoted context omitted.

Sure, but isn't it nice that you don't even have to read the paper to play with the full model, to see if the claims hold up, using the same Python tools you and everyone else uses?

Fair, but I would not call that "ecosystem".

It was an example. Please don't argue against a strawman.

Re: Swift for TensorFlow Shuts Down

#274

Post by renox »

eigenspace wrote: post #252
socialdemocrat wrote: post #232

Earlier quoted context omitted.

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for othe…

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of in static languages.

Sigh, isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)

Re: Swift for TensorFlow Shuts Down

#275

Post by sriku »

It's awesome to see this whole comment section be about Julia! As a community, evebtually we'll realize that we dot have the bandwidth to keep inventing the same thing over and over just so a new technique can be used efficiently. Currently, Julia is the only language that makes this kind of deep reuse possible by bein efficient through just-ahead-of-time compilation that specialises well through open multiple-dispatch.

Re: Swift for TensorFlow Shuts Down

#276

Post by johnnycerberus »

sanderjd wrote: post #212
_Wintermute wrote: post #86

Earlier quoted context omitted.

Here you are: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...

I always figured they would have chosen rust if it weren't for Lattner's sway (real or perceived) in the Swift compiler development community. One underestimated advantage of rust over swift in my view is that it has interested practitioners across a much more diverse range of problems spaces. I think it was always going to be hard to convince people to use a language for for ML when most of its practitioners are sol…

You can't be serious. Rust would just replace C++ in the current formula, you can't use Rust as if it was Python. ML people don't need to waste time proving memory properties at compile time, cmon!

Indeed, there were alternatives. Two already come to my mind, one is Scala (which syntax-wise is strikingly similar to Python) and Julia. Both having features like type-safety, macros, JIT, FFIs, etc.

Re: Swift for TensorFlow Shuts Down

#277

Post by FridgeSeal »

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.

Julia is like, the poster child for being able to mix and match and compose code and algorithms: Flux/Zygote can do auto-differentiation on the entire language without modification and you can drop in quite literally arbitrary Julia code as components of your network and it works.

> don't think that LLVM IR that uses is the best IR for the optimizations.

What makes you say this? They community has been able to do some pretty amazing things performance wise-e.g. pure-Julia implementation of BLAS/LAPACK reaching and in some cases exceeding performance parity, plus there’s been plenty of work in CUDA support for arbitrary Julia code, which is impressive.

Re: Swift for TensorFlow Shuts Down

#278

Post by Karrot_Kream »

swagonomixxx wrote: post #124
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.…

> 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…

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

Julia is not ML-ish. In fact, at first blush, Julia reads very similarly to Python. You even get list comprehensions in Julia!

> Sure, the code that you used to implement your model may improve slightly, but I don't see that code improving significantly. The fruit of your labor is usually a protobuf file (encoding the TensorFlow graph) or whatever your framework uses to encode the model you built. The code actually surrounding it is very minimal for most use cases.

It's really about breaking down the compositional boundaries here. Upthread, someone talked about how they could play around with Bayesian Nets by simply mixing Flux.jl (the differential programming library) with Turing.jl (the Bayesian programming library). Mixing Tensorflow/PyTorch with PyStan, for example, can be a nightmare. That's also why there's so many implementations of probabilistic programming frameworks (Edward, PyMC3, PyStan, Pyro, etc); they all use different underlying libraries. In Julia they just all compose together.

> 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

I find the change to be illuminating. Before I started spending more time with Julia, I would often do derivations on paper for more experimental work, and then implement it using TF/PyTorch in Python from scratch, reading other code where I could for some help. In Julia I can import a library and I'm ready to go. It feels just like working with math itself.

Julia also lets you compose long trains of operators together. That also helps when I'm doing long sessions in the REPL exploring data. It lets me define a few functions in a file, import the file, and just pipe (Julia has a pipe operator which is just function application) output between functions to plot data or calculate errors.

Moreover Julia is a lot more performant for REPL work than Python. In Python I'll usually work with a subset of a dataset to get an idea for it, then run a file with code to process the entire dataset. In Julia I can often prototype and run the algorithm in the REPL itself.

I also want to stress that Julia is quite a bit faster for REPL development, both in terms of raw speed

Re: Swift for TensorFlow Shuts Down

#279

Post by FridgeSeal »

mcast wrote: post #207
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.

And that’s good.

But they are notorious for being poor at keeping some projects and products alive.

Re: Swift for TensorFlow Shuts Down

#280

Post by eigenspace »

renox wrote: post #274
eigenspace wrote: post #252

Earlier quoted context omitted.

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of in static languages.

Sigh, isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)

Maybe it's just my julia indoctrination speaking but I find that rather ugly.

In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter.

We just write Type{paramemer}

Post reply on HN