Live data from Hacker News

Swift for TensorFlow Shuts Down

github.com

61–70 of 432 posts

Re: Swift for TensorFlow Shuts Down

#61

Earlier quoted context omitted.

What are some ways in which Python's type system should improve?

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

Re: Swift for TensorFlow Shuts Down

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

Re: Swift for TensorFlow Shuts Down

#63

Earlier quoted context omitted.

It seemed like Swift looked like a promising language for data science a few years ago. I'm not familiar with Swift. Can anyone provide additional context as to why the language seemed promising for data?

I disagree with the pitch, but the pitch I heard when this was announced was: * Swift lets you write code that's as concise as Python while still being fast, and therefore allows you to get away from the problem of having to write ML code in multiple languages (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.) * That the lack of static typing is a major pain point in Python…

> Swift lets you write code that's as concise as Python while still being fast,

> (TensorFlow is actually mostly C++, which makes it difficult for a Python developer to debug.)

To be honest, if I had to choose between Python and Swift I'd still choose Python. Swift is a nice evolution from Obj-C and all but it is nowhere near as simple as Python, or Ruby, or PHP, or Javascript, or Kotlin. And Apple's documentation of these things is pretty woeful at the best of times lately.

I also disagree with the pitch, is what I'm saying.

Re: Swift for TensorFlow Shuts Down

#64
post #27
post #6

Swift now being a 100% Apple-sponsored & owned project again makes me a bit nervous. Anyone knows if chris latner is at least using swift in his new company ? I have the feeling swift never really worked in the server side, data science is now officially a failure, and all that is left is now a very niche market of 100% native mobile development. I love this language, but i'm eager to see it handled by a proper found…

> a very niche market of 100% native mobile development I mean, it also works for native desktop development. And is there really an issue with that? Objective-C basically had no reason to exist beyond iOS/Mac programming and at least now we don't have god damn [myString stringByAppendingString:@"another string"].

I suspect that we'll be seeing ObjC for a long time, as the lower-level system language for Apple devices. I know that Apple still uses it for much of their system programming. No idea if that's by choice, or legacy (possibly both).

I was looking at the upcoming async/await stuff for Swift, and it's still not comparable to some of the lower-level threading systems.

That said, I have not done system programming for a long time (unless you count drivers). I think Swift is an almost ideal application-level language.

I'm not especially bothered by it being Apple-only. It works on all Apple-supported hardware, has a new application toolkit coming into play (SwiftUI), and has a very active development community. Spend some time on the Swift discussion forum to see some pretty heady discussions.

Re: Swift for TensorFlow Shuts Down

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

> adding automatic differentiation to Swift That work is still happening (as noted in the link). One of the primary engineers who was working on it at Google works at Apple now.

Speaking of shuffling, Dave Abrahams, (who was?) lead on the Swift standard library, moved to Google sometime back. Is he still doing Swift there?

Re: Swift for TensorFlow Shuts Down

#66
post #54
post #34

Earlier quoted context omitted.

What's Apple's incentive to do so?

Theoretically if Swift was an extremely marketable language across many domains, there would be more qualified developers available to work on software for Apple products.

But hasn't Apple managed to force a lot of developers to pick up the language anyways?

Re: Swift for TensorFlow Shuts Down

#67
post #33

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. I agree, but sadly none of the big cloud providers has any interest in pushing it - Google's got Go, AWS and Azure seem focused on Typescript.

I know AWS lets you just deploy a docker container, so you can use whatever tools you want -- anyone know about Azure and Google cloud?

Yes theoretically I think there is nothing stopping you from shipping Swift code on AWS. I am pretty sure you could do it in a lambda and you don't even need a docker container.

If you're talking about a container workflow, I'm pretty sure every cloud provider will support this just fine currently.

Re: Swift for TensorFlow Shuts Down

#68
post #36

S4TF from my (external) perspective was always more a (very cool!) programming language research project than anything else, at least since Lattner left. I would personally assume the shutdown was due to a combination of reasons: - There simply being no good reason for Python users to ever move to Swift. There is no big painpoint being solved for the broad ML user community - Organisational momentum lost with Lattner…

- There simply being no good reason for Python users to ever move to Swift. There is no big painpoint being solved for the broad ML user community As a swift and python user, I would have been really happy to be able to use swift for ML applications. Having a half way decent type system solves so many problems. But while I can see that from my vantage point, I know for a vast majority of the ML community python is "g…

I'm not sure if the Swift type system is half way decent in terms of machine learning applications. At least not without a lot of work. The data tends to be in specialized in-memory formats that tend to be opaque to the type system. The actual matrix operations involve dimension parameters that are likewise opaque to most type systems. So you still need to run code for the actual tensor graph compilation to validate if everything is correct. Python in notebooks does that instantly, Swift I suspect has a much longer delay.

Re: Swift for TensorFlow Shuts Down

#69
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 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 less silly mistakes where the NodeJS code feels like up and running by some miracle and everything can collapse due to something I did but could't catch it before something horrible happens.

Re: Swift for TensorFlow Shuts Down

#70

Earlier quoted context omitted.

What are some ways in which Python's type system should improve?

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 experience given that they're optional and you'll almost never get 100% of your code and its dependencies with correct and up to date signatures it's just a nuisance. Maybe in the right projects if all the devs are very thorough with them it can be helpful, but that's really not my experience. If at least it triggered an assertion at runtime when the type doesn't match it would be massively more useful. And even then, if you're so thorough with your typing, why not just use a proper statically typed language?

I really don't get why it's even there to be honest.

Post reply on HN