Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

231–240 of 432 posts

Re: Swift for TensorFlow Shuts Down

#231

Earlier quoted context omitted.

> In Julia, things are really small and composable. For example, you have a probabilistic programming library like Turing and a differentiable programming one like Flux, and it's trivial to implement some Bayesian neural networks. I was taken aback when looking at Turing for Bayesian modelling that the distributions were just the standard distributions found in the Distributions package! In Python, every Bayesian fra…

> but it all composes in Julia. You mean that, in Julia, we the users have to "compose" our own implementations of models (e.g. log probabilities), as opposed to using the already-made ones in Python?

More like... most of the scientific Python stack has settled on a third party library, NumPy, to provide support for numerical computing. That includes providing data types like arrays. Tensorflow doesn't use NumPy's data types, so if you want to use Tensorflow Probability, you need to convert everything you've done in NumPy (or things that are built on top of NumPy, like Pandas) to TensorFlow, and use TensorFlow's functions/methods to manipulate them.

(The same is true if you use something that's built on top of Stan or JAGS or BUGS or something else.)

In Julia's Turing.jl, everything is built around data structures that are first-class parts of Julia, so there's no need to have special Turing.jl versions of, say, probability distributions.

Re: Swift for TensorFlow Shuts Down

#232
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 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 other uses where it is more needed.

Re: Swift for TensorFlow Shuts Down

#233
post #115

Earlier quoted context omitted.

I agree that there is poor interoperability between the different DL / auto-diff frameworks in python. But I suspect the GP is referring also to things like scikit learn, numpy, plotting tools, PIL, opencv, pandas, etc. that make up the python ecosystem. I know that alternatives exist in other languages, but I don't know of an overall ecosystem that is as mature and interoperable as in python.

Then you haven't looked at Julia's ecosystem. It may not be quite as mature, but it's getting there quickly. It's also far more interoperable because of Julia's multiple dispatch and abstract types. For example, the https://github.com/alan-turing-institute/MLJ.jl ML framework (sklearn on steroids), works with any table object that implements the Tables.jl interface out of the box, not just with dataframes. That's jus…

I was using Julia before getting frustrated of how hard it is to use cutting edge AI on it, and decided to move to Python (fast.ai in specific, but moving more to PyTorch, as fast.ai 2's hook system made things much worse than if it would be something simpler).

I don't want mature, I want to use cutting edge AI algorithms and data pipelines on the newest NVIDIA GPU, so to make me move to Julia, the researchers have to move first.

At the same time for my non-AI data processing work I'm staying with Julia.

Re: Swift for TensorFlow Shuts Down

#234
post #149
post #69

Earlier quoted context omitted.

>I think Serverless would be another ideal use-case for Swift, where the productivity, clarity and correctness tools it offers would be a huge benefit. Oh yes, I would love to have Swift framework for Firebase on server, not only for iOS. Its atrocity to write the server logic in NodeJS after making the user App in Swift. Every time I switch from Swift to JS I deeply appreciate the beauty of Swift. On swift I do much…

Could it be that you have more knowledge of Swift and don't care/want to invest in understanding Node.js/JavaScript? I really enjoy writing backend code in TypeScript for Node.js. But loath having to write Swift code for iOS. I know a big part is my unwillingness to invest time in Apple's ecosystem and properly learn Swift.

I’ve used them all a lot and swift is certainly the easiest language out of the bunch. From a purely “safety” aspect it’s fantastic.

Ninja edit: I don’t mean easiest necessarily to learn. But easiest to use. Xcode is great.

Re: Swift for TensorFlow Shuts Down

#235
post #187

Looks like @throw6606 was right: https://news.ycombinator.com/item?id=24533937 . Does anyone know the status of https://ai.facebook.com/blog/paving-the-way-for-software-20- ...?

Reading that thread, I'm always so confused by HN posters who ask for evidence that would be impossible to provide without self-incriminating. Are they asking disingenuously, or are they just clueless?

Always makes me laugh. Perhaps something like 10% clueless, 80% disingenuous and 10% feel they are somehow entitled to information that's obviously sensitive or private.

Re: Swift for TensorFlow Shuts Down

#236
post #202

Earlier quoted context omitted.

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?

Most math books are written in a way where 1 is the first element. So if you take math examples and translate to code, it works more naturally.

Also this is how you talk normally. You don't talk about the zeroth-column or zeroth-row in daily speech. You talk about first column and first row.

Only reason 0 based indexing make sense to me is because I began programming as a teenagers and was forced to get accustomed to it. But I remember struggling with it. Yes when working with memory, pointers etc it is more elegant. But if you are not, then I think 1-based indexing looks better.

Re: Swift for TensorFlow Shuts Down

#237
Every time I see a post, about TensorFlow for Swift. There seems to be so many misconceptions about why this it was created. The top one being, oh it's Chris L's baby.

As a Software Engineer, who's been working on teams for the past 15 years and seeing the craft devolve, and the market saturate with people whom don't understand that fundamentals but memorize the frameworks, you need a language like Swift to bridge that gap.

It's hard enough to get people to program to an interface, let alone communicate what they are gonna return from a function or how a function behaves. 70% of people don't understand software engineering is legitimately just plumbing, they think its pretty much an artistic endeavour with no rhyme or reason. This makes it pretty difficult to stay on the same page, when building a product to scale up.

Having a strong type system solves that problem. When working with ML people my question 100% of the time is what does that function, return what type?, so I can build off what you are doing, or even debugging requires understanding of the type and the values.

It seems like team orientated programming is foreign to most people.

Swift has a low cognitive load pushing you to solve problems, with Software Engineering and reducing communication lead time between engineers.

All languages eventually converge Swift, I think Chris L has solved the language UI problem.

Re: Swift for TensorFlow Shuts Down

#238
post #51

Earlier quoted context omitted.

> Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Are you nervous about a language that is designed and supported by the largest and most successful company in the world? > very niche market of 100% native mobile development That "niche" is at least 1.5 billion devices. Devices bought by the 1.5 billion richest people in the world because they like them, not because their employer…

The Uber engineering disaster story from 2 months ago seems to suggest that Apple lacks dogfooding Swift internally: https://news.ycombinator.com/item?id=25373462

More like Uber spent too little time trying to keep their app development process manageable.

Re: Swift for TensorFlow Shuts Down

#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 science and Machine Learning Julia will always be a much better choice.

It is a pity Google did not go for Julia. Julia has gotten exceptionally far despite limited resources. With Google style resources, Julia could have been massive.

Despite modest investment, the Julia JIT beats almost anything out there. It would have been amazing to see what they could have pulled off if they had put the kind of resources that was put into the JavaScript V8 JIT into the Julia JIT.

Julia uses a method JIT, which are quick to implement, but which makes latency gets bad. Meaning if you load a whole new package, running the first function can cause some delay. With a JavaScript style tracer JIT added into the mix one could have probably managed to have both high performance and low latency.

Alternatively with more investment they could have had better precompile caching, meaning libraries that had been loaded in the past would JIT really fast. Julia does that today, but it could have worked a lot better than it currently does. It isn't that it can't be done, but it just requires resources.

Post reply on HN