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

301–310 of 432 posts

Re: Swift for TensorFlow Shuts Down

#301

Post by oflannabhra »

wrinkl3 wrote: post #33
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 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.

AWS has a Swift runtime for Lambda [0], and Amazon has an open source server framework for Swift, Smoke [1].

[0] - https://swift.org/blog/aws-lambda-runtime/

[1] - https://github.com/amzn/smoke-framework

Re: Swift for TensorFlow Shuts Down

#302

Post by ambicapter »

skohan wrote: post #199
zozbot234 wrote: post #191

Earlier quoted context omitted.

snake_case is a lot more readable than CamelCase, which is a huge benefit ergonomically. The keyboard layout is no big deal, one can easily change it or use shortcut-based autocomplete. Rust does use CamelCase for type identifiers, trait identifiers and enum constructors, and the contrast with snake_case also aids readability.

I disagree that it's "a lot " more readable. I have read a lot of camelCase code in my lifetime, and I can count on zero hands the number of times I ever had an issue parsing code due to the use of camelCase. Keyboard remapping seems like an extreme solution, and I don't want to train my fingers in such a way that when I sit down at a different workstation that doesn't have my .vimrc I can't type rust anymore. You do…

CamelCase is terrible as soon as you have an abbreviation in your function (like "DB"). I run into this extremely frequently at my place of work.

Re: Swift for TensorFlow Shuts Down

#303

Post by cutler »

stmw wrote: post #214

This is sad for the project itself, but I predict that the coming programming competition will be Rust vs. Go, not Swift -- as Swift was always a distant third among the "new" languages. And of course the more mature languages will continue to be popular and widely used for decades. In my opinion, Rust will end up winning this contest, but others have perfectly good arguments against that view. Unfortunately for serv…

I think Kotlin will become the dominant JVM language in time.

Re: Swift for TensorFlow Shuts Down

#304

Post by armadsen »

raydev wrote: post #82
ChrisMarshallNY wrote: post #64

Earlier quoted context omitted.

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…

We'll see it in legacy code for a long time, sure, but there's every indication that all new Apple frameworks are being written in Swift. Anyone starting a new project in Objective-C is in the minority.

We'll see. Off the top of my head, only Combine and SwiftUI are Swift only for now. And Combine has specific features that are explicitly meant to make it interop with ObjC (and @objc Swift) objects, e.g. KeyValueObservingPublisher. The other "hot new" Apple frameworks, like CoreML, ARKit, HealthKit, ResearchKit, etc. are all still written in and usable from Objective-C. They _are_ starting to use Swift(UI) in UIKit, but so far continue to wrap it in an Objective-C interface.

Re: Swift for TensorFlow Shuts Down

#305

Post by sanderjd »

johnnycerberus wrote: post #276
sanderjd wrote: post #212

Earlier quoted context omitted.

I always figured they would have chosen rust if it weren't for Lattner's sway (real or perceived) in the Swift compiler development community. One underestimated advantage of rust over swift in my view is that it has interested practitioners across a much more diverse range of problems spaces. I think it was always going to be hard to convince people to use a language for for ML when most of its practitioners are sol…

You can't be serious. Rust would just replace C++ in the current formula, you can't use Rust as if it was Python. ML people don't need to waste time proving memory properties at compile time, cmon! Indeed, there were alternatives. Two already come to my mind, one is Scala (which syntax-wise is strikingly similar to Python) and Julia. Both having features like type-safety, macros, JIT, FFIs, etc.

None of this is less true for swift. The whole idea is that there may be an advantage to better static analysis that overcomes the perceived downside of using a language with a strict compiler and lots of rules. That idea may or may not be worthwhile, but it is equally applicable to swift and rust.

Julia I agree but Scala strikes me as a bit of a non sequitur. It is much more complex and foot-gunny (and thus difficult for scientists who only know python to get right) than either swift or rust, and much more difficult for static analyzers.

Re: Swift for TensorFlow Shuts Down

#306

Post by moelf »

renerthr wrote: post #221
Karrot_Kream wrote: post #101

Earlier quoted context omitted.

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

> but it all composes in Julia. You mean that, in Julia, we the users have to "compose" our own implementations of models (e.g. log probabilities), as opposed to using the already-made ones in Python?

for example, if you have a relu activation function, it's literally just: relu(x) = max(zero(x), x)

now python has like 5 identical numpy-like API re-implemented in multiple framework. That's where resources is wasted (unnecessarily)

Re: Swift for TensorFlow Shuts Down

#308

Post by [deleted] »

timClicks wrote: post #287
zozbot234 wrote: post #191

Earlier quoted context omitted.

snake_case is a lot more readable than CamelCase, which is a huge benefit ergonomically. The keyboard layout is no big deal, one can easily change it or use shortcut-based autocomplete. Rust does use CamelCase for type identifiers, trait identifiers and enum constructors, and the contrast with snake_case also aids readability.

Sorry to be pedantic, but PascalCase is different from camelCase.

[deleted]

Re: Swift for TensorFlow Shuts Down

#309

Post by yyyk »

stmw wrote: post #214

This is sad for the project itself, but I predict that the coming programming competition will be Rust vs. Go, not Swift -- as Swift was always a distant third among the "new" languages. And of course the more mature languages will continue to be popular and widely used for decades. In my opinion, Rust will end up winning this contest, but others have perfectly good arguments against that view. Unfortunately for serv…

The idea there's one language for everything was false even during C's heyday. Your list contains languages for very different uses.

Rust will eventually win low-level programming from C++, but massively networked applications will always be slightly easier in Go. Swift is a bytecode language, it competes against .NET (mainly C#) and JVM (Java and variants), not Rust or Go.

IMHO Swift seems to losing when not tied to Apple's ecosystem, its future will be as some Apple-niche language.

Re: Swift for TensorFlow Shuts Down

#310

Post by dnautics »

cs702 wrote: post #211
lostmsu wrote: post #206

Earlier quoted context omitted.

Nystromformer attention layer is actually pretty simple. You can reimplement it in a few minutes.

Sure, but isn't it nice that you don't even have to read the paper to play with the full model, to see if the claims hold up, using the same Python tools you and everyone else uses?

To be honest that is not really true for many ML implementations from papers. Often, I will pull a repo and it will be half-baked, or, only works on python 2.4, or have a broken dependency on something or another (zmq was common issue for a hot sec), or not publish weights, or be in tf when I want torch, or be in torch when I want tf, etc.
Post reply on HN