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

101–110 of 432 posts

Re: Swift for TensorFlow Shuts Down

#101

Post by Karrot_Kream »

nextos wrote: post #60
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…

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

> 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 framework has its own implementation of everything from distributions to log probabilities, but it all composes in Julia.

> It's small and beautiful, but it needs more manpower to compete against Python.

Agreed. Docs of major projects are still incomplete or non-existent, there's a lot of projects that have been nigh abandoned (cough naive bayes cough), and the composability of Julia coupled without strong leadership leads to an ecosystem of overlapping functionality. Still, I hope by leveraging PyCall, Julia can overcome some of these issues.

Re: Swift for TensorFlow Shuts Down

#102

Post by jshier »

jtdev wrote: post #71
msie wrote: post #29

Swift compared to Python was getting way too complex. Why would anyone learn Swift for data science when Python will do?

Agreed, Swift has an obsession with functional programming that is just so off-putting to me and I suspect many others.

This is hilariously wrong. Actual fans of functional programming would disagree with you, as there are several things Swift doesn't do to enable pure functional programming.

Re: Swift for TensorFlow Shuts Down

#103

Post by jshier »

jtdev wrote: post #62

Not surprised that this project had trouble gaining traction given Swift's obsession with shoe-horning functional concepts into every crevice of the language, e.g., I can't get through a single Swift tutorial without having to get into closures.

Closures aren't really a functional concept, they can just be used functionally. You'll see a big reduction in closure usage when the new concurrency features ship.

Re: Swift for TensorFlow Shuts Down

#104

Post by adsharma »

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…

Python type system is improving. Another point in this ease of use vs type safety spectrum is python -> type safe language static compilation.

I don't know which one is the best. So I've been experimenting with several.

https://github.com/adsharma/py2many

Re: Swift for TensorFlow Shuts Down

#106

Post by mrtksn »

simonbarker87 wrote: post #76
mrtksn wrote: 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…

It doesn’t solve the issue of JS but NestJS feels like a more robust way to make a server in JS - and the docs are great.

Thanks, I don't really need large framework for full blown app though.

Re: Swift for TensorFlow Shuts Down

#107

Post by iujjkfjdkkdkf »

BadInformatics wrote: post #78
xiphias2 wrote: post #40

Earlier quoted context omitted.

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 Given how divergent the current crop of ML frameworks are, is this really a realistic expectation? Having played around with Julia and Flux for ML, I find I have to do just as much rewriting when translating e.g. TF -> Flux as TF -> PyTorch. You get some limited mixing and matching with Caffe2 Torch and TF JAX, but that bre…

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.

Re: Swift for TensorFlow Shuts Down

#108

Post by 6gvONxR4sf7o »

skohan wrote: post #88
6gvONxR4sf7o wrote: post #61

Earlier quoted context omitted.

I don't think that's accurate. Python's type system is largely defined by mypy + the annotations, in addition to runtime python. In that regard, python's type system has been evolving really quickly, and it's becoming something quite interesting. I'm a fanboy of static type systems, and in the last bunch of years, python's type system has gone from just bearable to really useful. I'm excited to see where it goes from…

But to some extent isn't it always going to be bolted-on and dependent on library authors to which extent it's consistent?

The dependence on library authors is always a challenge in any language. You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]).

There are some interesting further add ons that seem very python, allowing you to go further. For example, with a pandas dataframe you can just say your type is a dataframe which isn't so useful, but it's possible to hack your own types onto it in the vein of https://github.com/CedricFR/dataenforce, or use things like https://smarie.github.io/python-vtypes/ to get smarter typing on things the authors didn't type. I expect that trend will continue.

What fascinates me about python's types is actually the very fact that they are bolted on. You have a language that lets you do crazy things and a type system trying to catch up and make it convenient to verify those crazy things. It's a nice complement to the usual developments of verifying all of the things and slowly extending the set of things you can do.

Re: Swift for TensorFlow Shuts Down

#109

Post by mumblemumble »

simias wrote: post #70
superbcarrot wrote: post #57

Earlier quoted context omitted.

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

> the fact that they are completely ignored by the standard implementation. They're glorified comments.

Not quite. You can reflect on and interact with them at run-time, too. This does make it possible to implement run-time checking as a library solution.

I can't speak to why run-time checking wasn't built into the language as a default behavior, and the PEP doesn't explain why (though perhaps the answer is in the mailing list), but one possibility is that it would be wasteful. Most functions that are only prepared to accept certain types already have some form of run-time type check baked in, either explicitly or incidentally, so adding a second check would likely introduce overhead without producing a whole lot more type safety.

Re: Swift for TensorFlow Shuts Down

#110

Post by swagonomixxx »

simias wrote: post #70
superbcarrot wrote: post #57

Earlier quoted context omitted.

It fundamentally can't be improved in a significant enough way and still be Python. The more realistic options are to be okay with Python's type system (I personally am) or to look at different languages if you really want something more robust.

I agree with you, although I must say that as an occasional Python user the way type hints are implemented absolutely baffles me. In particular the fact that they are completely ignored by the standard implementation. They're glorified comments. Given how opinionated the Python maintainers can be, it baffles me that they accepted to get these optional, noisy, half backed type hints into the core language. In my exper…

Type hints are not perfect, but IMO after using them for a while, they are significantly better than nothing.

If you do the legwork, you can get mypy[0] type-checking done on your codebase in a way that is similar to how TypeScript does type-checking. There are stub files that are provided by project maintainers that are then used by mypy to infer things like e.g the return type of a function.

Type hints are also inline in the code, and not technically comments. They can be retrieved from class attributes using facilities from the standard library [1] and can facilitate other tooling that is specific for your project or that are more general.

> And even then, if you're so thorough with your typing, why not just use a proper statically typed language?

That would remove a lot of the benefit of choosing Python. Python is dynamically typed. Type hints make it possible to do type checking statically, but with a lot of extra leg work (as I described above). Making Python itself statically typed is not something that would interest 99% of the Python community IMO.

[0] http://mypy-lang.org/

[1] https://docs.python.org/3/library/typing.html#typing.get_typ...

Post reply on HN