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

171–180 of 432 posts

Re: Swift for TensorFlow Shuts Down

#171

Post by marcinzm »

skohan wrote: post #151
swagonomixxx wrote: post #136

Earlier quoted context omitted.

> Having a half way decent type system solves so many problems What problems does it solve for you? When building ML applications I mean. Because that's what S4TF was supposed to be. ML researchers produce models that are used by ML applications for a particular purpose. The code to train the model _could_ be statically typed, sure, but I really don't see what the improvement would be. It would be more verbose, less…

My guess is that's because ML researchers typically have not spent much time with statically typed languages. I was also once convinced that static typing was not so valuable - when I was working a lot with js, python and ruby, but the more time I spend with static typing the more I like it. There is an "activation energy" to overcome with static typing: when you first start it feels like a tedious burden to have to…

I've done a lot of statically typed code and have gone to conference where Haskell was on the keynote. I've done ML work in both dynamically and statically typed languages. For the ML work I do I don't honestly see the advantage. Most of the complexity is in the matrix and data operations which existing type systems don't check. And the type annotations and IDE support is good enough to catch most of the other boring errors. In my experience most deep learning ML models are also not particularly complicated code from a code perspective.

Re: Swift for TensorFlow Shuts Down

#172

Post by girvo »

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?

For what it’s worth, TypeScript had somewhat of the same problem, and yet these days it’s rare for me to find a well known library that doesn’t include type definitions!

Re: Swift for TensorFlow Shuts Down

#173

Post by skohan »

ZeroCool2u wrote: post #155
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.…

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…

Language aesthetics do matter. Broadly it seems like we've accepted that "c like" syntax - including brace-delimited blocks and zero-based indexing - should be the norm for programming languages. Any language which goes in a different direction should have a very strong reason to do so, because any deviation will be an obstacle for adoption.

I share your frustration with the `end` keyword - it's just needlessly verbose, and for something used so frequently it makes sense to be as terse as possible.

I have some similar quibbles with Rust syntax: I know it's a minor issue, but I'm really disappointed that snake_case was adopted. It's just ergonomically inferior to camelCase in every measure. It's one more character to type for every word, and on top of that, on a US keyboard, the underscore character is a pinky key way far away from the center of the keyboard. Making this one of the most frequently typed characters in the language makes no sense.

Re: Swift for TensorFlow Shuts Down

#175

Post by mrtksn »

adevx wrote: post #149
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…

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 used to work with web technologies but I got overwhelmed with the complexity of the tooling.

For example, TypeScript is nice but it's not a "real" language in a sense that you can write something in it and expect it to work when it's fed into the compiler or interpreter. To use it, you need to set up an environment where all the moving parts are working in harmony and the code you write in Typescript is transcribed into the actual code that NodeJS and the browser will understand and that is JS. The debugging of unusual bugs and doing something non-conventional instantly becomes multiple times harder because you have layers and layer over the actual stuff that is executed which means you loose the browsers or runtimes debug capabilities since those would rarely tell anything useful about the pre-transcription code.

Sometime you have a library where someone a few years back tried to do something similar to your idea but never had a complete solution and stopped working on it and when you try to benefit from this work to build on top of it, you find out that you need to modify you working environment to support some spacial case of legacy code. You do that and it all falls apart, now you must choose to try to fix it or give up and restore your setup. It's just horrible.

The greatest thing about working with Swift on iOS is that starting something new is as easy as creating a new Word document so you can start working on your idea right away without worrying about the tooling and see where it goes. On the JS world, I used to be exhausted and loosing all my motivation by the time I have my environment ready to go. Templates and project starters tend to be no good because they are all opinionated that you must be creating a list or a blog app. They all need extra work for a good clean start and that clean start often is too customised to be used as a general use case template.

There are so many solutions for the same problem in the Web Tech world, each comes with its own shortcomings and taht's how someone else creates the next framework. On iOS it's easy, the answer is UIKit and SwiftUI if you feel more adventurous and bleeding edge.

Re: Swift for TensorFlow Shuts Down

#176

Post by rezahussain »

joeblau wrote: post #19

I'm looking through the meeting notes[1] linked from the archive PR[2] and it looks like there hasn't been much activity on the project recently. Can anyone with more insight provide an explanation on what happened? [1] - https://docs.google.com/document/d/1Fm56p5rV1t2Euh6WLtBFKGqI... [2] - https://github.com/tensorflow/swift/commit/1b1381ccb89a342ba...

https://twitter.com/bradlarson/status/1360230872658698244

https://twitter.com/texasmichelle/status/1360287563898974211

I think we just have to wait for the meeting video to be posted

Re: Swift for TensorFlow Shuts Down

#177

Post by mrtksn »

jiofih wrote: post #168
mrtksn wrote: post #106

Earlier quoted context omitted.

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

Swift and UIKit are already a much larger API than any node framework in existence.

They have good defaults and Xcode is a good IDE with full support of these frameworks, Swift is a good language with sensible conventions so you don't really need to learn that much.

When you don't know something you can start typing keywords and see what Xcode autocompletes for and read the explanation about that function from the documentation that is provided to you right there. It's not perfect, sometimes there's no documentation but it's not a big deal as you can look into source files or try it out to see how it behaves.

Re: Swift for TensorFlow Shuts Down

#179

Post by willxinc »

BadInformatics wrote: post #5

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

Looks like your link was cut off: https://ai.facebook.com/blog/paving-the-way-for-software-20-...

(Missing the -with-kotlin at the end)

Re: Swift for TensorFlow Shuts Down

#180

Post by mleonhard »

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 guess it goes to show that the governance and availability of a language have a lot more to do with adoption than the merits of the language itself.

Nearly every Google project eventually gets abandoned because the engineers that made it get promoted and move on to their next promotable projects. The root cause is the ongoing failure of Google's leaders to align employee incentives with the long-term interests of the company or human society.

Even if S4TF had become popular, I expect it still would become neglected and rot like most Google projects.

Post reply on HN