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

311–320 of 432 posts

Re: Swift for TensorFlow Shuts Down

#311

Post by hughcrt »

mrtksn wrote: post #175
adevx wrote: post #149

Earlier quoted context omitted.

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…

Deno seems to address some of the shortcomings of Node. I haven't used it on a "real" application yet, but the built in support for Typescript, formatter, linter etc. reduce the complexity of tooling, especially for server code.

But I agree, Swift is a pleasure to work with.

Re: Swift for TensorFlow Shuts Down

#312

Post by lostmsu »

The_rationalist wrote: post #296
lostmsu wrote: post #205

And TensorFlow for C# is alive and kicking: https://losttech.software/gradient.html I guess this is sort of an ad. Swift was a weird choice for statically typed TensorFlow, being only popular on the platform, that does not have GPU/TPU support in TensorFlow, which is, basically, a requirement for any serious work. The fact, that they had to fork the compiler did not help either. TensorFlow for C# is much like TensorF…

Do you know if tensorflow for Java is as mature as tensorflow for C#? Btw of you didn't saw it, Facebook is implementation support for auto differentiation to the Kotlin compiler

TensorFlow for Java is mostly for running pretrained models. Even though it might have training capabilities, they are extremely limited.

Re: Swift for TensorFlow Shuts Down

#313

Post by UncleOxidant »

socialdemocrat wrote: post #225
selectodude wrote: post #146

Earlier quoted context omitted.

The outcome is more important than the code. While that sounds very elegant, what does it actually add?

The Julia approach gives quicker development. Some of these ML libraries such as Flux are so small that almost anyone can read the code and learn how it works and make modifications. It is not for anyone to jump into TensorFlow. The irony here is that tiny Julia libraries give the same power as much larger Python libraries which require highly specialized and trained developers to evolve and maintain. With Julia it i…

> The challenge for the Julia community today is really to make people new to the environment aware of this.

^This. As we're seeing here in the discussion thread Python folks don't really realize what they're missing when we're talking about composability of of libraries in Julia - it's kind of difficult to explain the impact on productivity without people actually trying it out. I think Julia and Flux are getting to the point where they're quite useable and comparable with PyTorch. Also some of the Neural ODE stuff and differentiable programming in SciML seems just a lot easier to implement than it would be in Python.

Re: Swift for TensorFlow Shuts Down

#314

Post by lostmsu »

astrange wrote: post #266
lostmsu wrote: post #205

And TensorFlow for C# is alive and kicking: https://losttech.software/gradient.html I guess this is sort of an ad. Swift was a weird choice for statically typed TensorFlow, being only popular on the platform, that does not have GPU/TPU support in TensorFlow, which is, basically, a requirement for any serious work. The fact, that they had to fork the compiler did not help either. TensorFlow for C# is much like TensorF…

> Swift was a weird choice for statically typed TensorFlow, being only popular on the platform, that does not have GPU/TPU support in TensorFlow, which is, basically, a requirement for any serious work. The fact, that they had to fork the compiler did not help either. This is available now (not sure if it's in mainline). https://blog.tensorflow.org/2020/11/accelerating-tensorflow-...

M1 is not a good replacement for Nvidia GPU, especially a professional one.

Re: Swift for TensorFlow Shuts Down

#316

Post by sida »

freedomben wrote: post #244
socialdemocrat wrote: post #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…

Julia is fascinating to me, and I don't do any ML (currently). Julia seems like such a well designed language. I'm excited to see where it goes.

As weird as it sounds, the only thing that stops me from trying Julia is 1 indexing

Re: Swift for TensorFlow Shuts Down

#317

Post by mikkelam »

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

Sure. People were asserting that the second chris lattner left google, see https://news.ycombinator.com/item?id=22161780

Re: Swift for TensorFlow Shuts Down

#318

Post by arcturus17 »

belval wrote: post #185
onelovetwo wrote: post #153

Earlier quoted context omitted.

Its becoming like the same grasp js has on the web...which is sad to see.

This is a false equivalence of the first order. What makes JS impossible to dethrone is that whatever replaces it would need to be supported by a critical mass of web browsers, which just won't happen. AI/ML on the other hand has no such restriction. Your new startup could build all their ML models in Java with DeepLearning4J and it would probably work fine. Python is used because it's easy to work with for experimen…

Well you could also build your web startup in a compile-to-JS language and barely ever touch JS, and you’d also be fine, right? (Maybe in rare cases for interop, debug, etc)

At any rate you’re right - the dominance of each language for their respective use cases (JS-Web / Py-ML) emanates from different sources.

Re: Swift for TensorFlow Shuts Down

#319

Post by adgjlsfhk1 »

socialdemocrat wrote: post #225
selectodude wrote: post #146

Earlier quoted context omitted.

The outcome is more important than the code. While that sounds very elegant, what does it actually add?

The Julia approach gives quicker development. Some of these ML libraries such as Flux are so small that almost anyone can read the code and learn how it works and make modifications. It is not for anyone to jump into TensorFlow. The irony here is that tiny Julia libraries give the same power as much larger Python libraries which require highly specialized and trained developers to evolve and maintain. With Julia it i…

"I don't think most people realize how powerful Julia isI don't think most people realize how powerful Julia is"

I don't think I realize how powerful Julia is, and it's my main language (and I have written libraries, and contributed to Base).

Re: Swift for TensorFlow Shuts Down

#320

Post by mrtksn »

jiofih wrote: post #282
mrtksn wrote: post #267

Earlier quoted context omitted.

I use VSCode, it’s helpful but It’s not remotely the same. With TS it’s better when the devs included documentation.

It will use typescript type definitions when available, even if you’re writing plain JS. Auto complete works perfectly, what’s not remotely the same?

It's not the same because in JS you usually would use a large number of libraries with varying degree of documentation and different conventions. Also, you would loose autocomplete when you expect to receive something as a parameter instead of defining it in that closure.

The basic language API is not that large, the benefit of autocomplete discovery comes when you have autocomplete on custom types of a specific framework accompanied with proper documentation.

Post reply on HN