Live data from Hacker News

Why Swift for TensorFlow?

github.com

81–90 of 151 posts

Re: Why Swift for TensorFlow?

#81

I still don't understand why they would choose Swift over C#? They complain about C#/Java having "highly dynamic constructs" but correct me if I'm wrong but isn't swift also a GC/OOP like Java and C#? I don't think Swift has any inherent objective advantages over c#. I think it would have been a better decision to go with C# over Swift as Microsoft has a clear roadmap with the language and it is already supported on…

While I do think the choice of Swift is kind of weird, you are wrong about Swift being garbage collected (it uses Automatic Reference Counting). It also compiles to actual machine code (rather than an intermediate representation for use in a VM).

Re: Why Swift for TensorFlow?

#82
I am surprised Dart is not mentioned at all (maybe implied under the OOP languages?). While Flutter and Tensorflow are very different usecases, I am surprised there is nothing in the document on why Dart specifically would be a good choice. I believe if they used Dart for Tensorflow as well, the community would be able to get behind the idea that will not be an abandoned language.

Re: Why Swift for TensorFlow?

#83
post #5

I also wonder how much of this coincidentally lines up with Chris Lattner landing at Google. As Chris will admit, and as was left out of this analysis, Swift has also been given the humble goal of achieving world domination. All joking aside I'm very thrilled about this and have enjoyed tremendously watching the Swift language mature since its launch due in large part to the open source community and the Swift team's…

It's not a coincidence at all

Re: Why Swift for TensorFlow?

#84

Earlier quoted context omitted.

From the article: We believe that Rust supports all the ingredients necessary to implement the techniques in this paper: it has a strong static side, and its traits system supports zero-cost abstractions which can be provably eliminated by the compiler. It has a great pointer aliasing model, a suitable mid-level IR, a vibrant and engaging community, and a great open language evolution process. A concern with using Ru…

As I pointed out in two lengthy comments on day one[1][2], that reasoning is nonsense. If Chris wants to use the language he created in this new endeavor for machine learning simply because he made it , that's totally fine and completely his prerogative, but he should just say so, rather than trying (and failing) to convince people that other languages aren't better suited for this task. From my point of view, a weak…

Julia compilation time is much improved in 1.1 and they are working on tiered compilation to make it better.

Re: Why Swift for TensorFlow?

#85
post #56

Earlier quoted context omitted.

Sorry, I just didn't want to give people the impression that it's more difficult than other languages. To upgrade you'd just have to remove the original install directory and untar the new release. I'm not familiar with Snap, but I did find https://snapcraft.io/swift Also, upgrading will be less common than Rust since almost everyone uses the latest release/toolchain. There's not really a reason to use the daily buil…

For comparison, for Go, it's "sudo snap refresh go". For Rust it's "rustup update stable". I mean, how hard would it be to properly package this stuff, and why should tens of thousands of users deal with all this manual downloading and unpacking? Assuming, of course, that Swift folks don't deliberately want to make the language unpolular, like Haskell.

I agree they should put the effort into having an easy "apt-get" solution. On the other hand, your original question was whether there is a standard way of installing Swift on Ubuntu. The answer is a very clear YES: download the latest tarball of the binaries from the Download page and unzip.

Re: Why Swift for TensorFlow?

#86

Earlier quoted context omitted.

Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…

Correctness verification at the level that data scientists need can generally be achieved with optional typing (presuming a well designed type system)

Perhaps! I personally think it's still a very young field, and there's likely a spectrum of professionals who prefer some strong degree of typechecking.

This is being explored with "Live Checking" in F#[0], which offers a form of static typing over TensorFlow without actually forcing you to express every complex interaction with data in types.

[0]: https://github.com/fsprojects/TensorFlow.FSharp#live-checkin...

Re: Why Swift for TensorFlow?

#87
post #5

I also wonder how much of this coincidentally lines up with Chris Lattner landing at Google. As Chris will admit, and as was left out of this analysis, Swift has also been given the humble goal of achieving world domination. All joking aside I'm very thrilled about this and have enjoyed tremendously watching the Swift language mature since its launch due in large part to the open source community and the Swift team's…

What do you mean? This was not in process before Chris came, it was a project he suggested and started pushing on? What is there to be coincidental?

I think they mean the exact opposite of "coincidental", in the sense of "hmm... is this a coincidence" (no, it isn't)

Re: Why Swift for TensorFlow?

#88

Earlier quoted context omitted.

What do you mean? This was not in process before Chris came, it was a project he suggested and started pushing on? What is there to be coincidental?

I think they mean the exact opposite of "coincidental", in the sense of "hmm... is this a coincidence" (no, it isn't)

I get that, but i guess i don't understand what there is to be guessing at at all.

I think it's been pretty straightforward that Chris joined Google and started this project. You don't have to wonder if that's a coincidence, that's what he's happy to say happened.

Re: Why Swift for TensorFlow?

#89

Earlier quoted context omitted.

More to the point static typing is just not that important for data scientists. Arguably it's not that important for backends devs either (e.g. lisp, erlang).

Should be prefaced with, "I think". Having done user research on this by speaking to data scientists, I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning. Much like how TypeScript is seen as a revelation to hordes of JavaScript programmers who have never used static types before, the ability to get some level of correctness verific…

> I can say that static typing is desired by a nonzero number of who practice what we would consider to be data science and machine learning

Who would trade static typing with fast prototyping any time.

Data science is a really nebulous term covering many drastically different domains of CS. Many DS I talked with, don't really produce code, they do coding to produce analysis, which is the actual delivery. For them, code is ad-hoc and disposable, created on demand and left in the dust until rediscovered when mission comes.

Some of the code do survive and enter production stage, I guess that is where they would seek some assurance from static typing. But I do think they could learn to mitigate most of pain if they can commit themselves to write some unit-tests/functional tests, yet such awareness is rare among the DSs I know and worked with.

So all in all, yes static typing MIGHT help, in some way, but I don't think it addresses the underlying pain point as much.

Re: Why Swift for TensorFlow?

#90
post #29

It's interesting how it's going to play out. On one hand side, Swift is a pleasant language to work with (despite its infancy). But on the other, having a Tensorflow API doesn't suddenly give it a bunch of libraries for statistics, comp. vision, modeling, visualisation, etc. that Python/R/Julia cough MATLAB cough have. Nowadays, it's difficult enough to convince people to drop e.g. MATLAB for R or Python for Julia (l…

I feel like GraalVM has a chance to solve some of this at least. I wonder if anyone will make an Octave GraalVM frontend, they already have one for R.

Isn't Graal an Oracle thing? I don't understand why anyone would want to touch that even with a 10-foot pole.
Post reply on HN