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.
Swift for TensorFlow Shuts Down
61–70 of 432 posts
Re: Swift for TensorFlow Shuts Down
#62Re: Swift for TensorFlow Shuts Down
#63Earlier 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…
> (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
#64Swift 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 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
#65No 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.
Re: Swift for TensorFlow Shuts Down
#66Earlier 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.
Re: Swift for TensorFlow Shuts Down
#67Earlier 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?
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
#68S4TF 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…
Re: Swift for TensorFlow Shuts Down
#69It'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…
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
#70Earlier 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.
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.