3 ms·

To the original point, yes, you're right. I see there's a nascent community, still fairly small outside the iOS community but it exists. But to add to my point

by wenc 8y ago

To the original point, yes, you're right. I see there's a nascent community, still fairly small outside the iOS community but it exists. But to add to my point... unfortunately, none of those are in the realm of numerical computation or anything remotely connected to the Tensorflow domain. If a Tensorflow user needed to interact with the ecosystem, it would seem that there's not much in place because the folks currently in the Swift community don't work in those fields, whereas Julia folks do. It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc. Now that is not to say that with Google's backing, the community won't shift, but that will take time and uptake is uncertain, whereas with Julia that community alignment already exists. And the Julia community didn't start out being platform-centric, so it has a broader base. I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary. Again, not to put Swift down. It's just a very curious choice for Tensorflow is all.

skohan 8y ago
> It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc. Actually I think thst's something which is very strong about the TensorFlow for Swift effort: it allows you to call Python out of the box, so all the Python tooling which is currently available to data scientists is immediately available. It seems the goal of the project is to allow users to immediately take advantage of the convenience of swift (especially the type system) in an incremental way, leaving most of their workflow intact. They're also already bringing a lot of numerical computing utilities into the language itself. It already has native linear algebraic operators like dot product built in, and automatic differentiation is coming. > I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary. So I currently experiment with it using Docker, which you could do on Windows. I know that's not as good as official support, but it is possible. Anyway, I haven't worked with Julia beyond playing with the REPL a bit, and maybe it would have also been a great choice for TensorFlow. At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I find it very nice to work with and I would be happy to use it in more places where Python is currently the main option. Also the TensorFlow team seems to be doing some very interesting things with it.
- wenc 8y ago
  Thanks for your thoughts and for the additional info. > At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family. The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were. But it's just a feeling. I will leave it at that.
  - skohan 8y ago
    > The community vibe alignment isn't quite there with Swift -- it had no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and depth as it were. It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic. To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal. But that's just my biased opinion.
    - wenc 8y ago
      To use your analogy: A good saw is spec'ed by a woodworker and made by a metalworker. A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software. At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.

by wenc 8y ago

skohan 8y ago

> It's not just C interop, but the presence of mature dataframe libraries, a linear algebra layer (that doesn't involve direct calls to BLAS or Lapack), etc. Actually I think thst's something which is very strong about the TensorFlow for Swift effort: it allows you to call Python out of the box, so all the Python tooling which is currently available to data scientists is immediately available. It seems the goal of the project is to allow users to immediately take advantage of the convenience of swift (especially the type system) in an incremental way, leaving most of their workflow intact. They're also already bringing a lot of numerical computing utilities into the language itself. It already has native linear algebraic operators like dot product built in, and automatic differentiation is coming. > I use Windows at work (because bigcorp) and there's currently no officially sanctioned Swift I can install, but there's an official Julia binary. So I currently experiment with it using Docker, which you could do on Windows. I know that's not as good as official support, but it is possible. Anyway, I haven't worked with Julia beyond playing with the REPL a bit, and maybe it would have also been a great choice for TensorFlow. At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I find it very nice to work with and I would be happy to use it in more places where Python is currently the main option. Also the TensorFlow team seems to be doing some very interesting things with it.

wenc 8y ago
Thanks for your thoughts and for the additional info. > At the same time, I do wonder if there's an irrational component to the reticence around Swift for TensorFlow based on the fact that people still identify it as a somehow proprietary language. I'm sure there's some of that, but my feeling is -- and I speak only for myself and maybe some in my tribe -- that it isn't so much the perception of Swift as a proprietary language but more that it isn't a language designed for DS/ML/applied math and maybe the Swift community doesn't really get our needs, whereas Julia is and does. Python feels like the latter too -- it was swiftly adopted in DS/ML because it was already used heavily in scientific computing, which is part of the same family. The community vibe alignment isn't quite there with Swift -- it has no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and a kind of depth as it were. But it's just a feeling. I will leave it at that.
- skohan 8y ago
  > The community vibe alignment isn't quite there with Swift -- it had no history in numerical computation and it came into the scene because a team at Google said so, whereas Julia and Python grew organically from the communities that do the same work we do, and were trying to solve the same problems we were. There's skin in the game and depth as it were. It's an interesting perspective, and I think my own tribal bias as a software engineer plays in to my gut feeling on the topic. To me it's natural to see it in these terms: who's going to make a better saw: a metal worker or a wood worker? The woodworker might know exactly what he wants out of a saw, but the metal worker is a heck of a lot better making things out of metal. But that's just my biased opinion.
  - wenc 8y ago
    To use your analogy: A good saw is spec'ed by a woodworker and made by a metalworker. A great saw is made by a metalworker who is also a woodworker. This latter bit is true for the Python community, at least for the people and companies who write DS/ML tooling in Python. Excepting hobbyist/academic tooling, Python has some really high-quality DS/ML tooling built by people who know software and the problem domain. Julia seems to following the same path though it's not as far along as Python, but from what I've seen, Julia folks are numerical computation folks who also really understand software. At present, Swift is like a metalworker who's seen saws used by woodworkers but isn't really into woodworking (yet) and doesn't have a whole lot of experience with the woodworking craft.