4 ms·

I don't want to be that guy, but if they were going with a heavy handed language anyway, why not Rust? It has a good multiplatform support and most of the same

I don't want to be that guy, but if they were going with a heavy handed language anyway, why not Rust? It has a good multiplatform support and most of the same benefits of Swift.

TACIXAT 7y ago
The article addresses this. Data scientists probably don't want to manage memory.
- ShinTakuya 7y ago
  But that's not what you do in Rust? That's more of a C++ thing. I think you'd be surprised, Rust is much more similar to Swift than you'd think. The biggest layer of complexity is fighting with the borrow checker in some cases, but that only really comes into play when you want to write something concurrent.
  - simias 7y ago
    I love Rust and I don't know much about data science but from my understanding many data scientists are not hardcore programmers it the same way that many programmers are not necessarily great at sysadmin. It's a tool, but it's not really the core of their job. In particular they mention Python being very popular in these circles. Switching from garbage collected and dynamically typed to manual memory management + static typing + borrow checker + trait-based generics is going to be a deep dive for these people. Maybe they'd end up better off in the end though, who knows. I personally think that dynamic typing and GCs are overrated and their benefits overstated but that's obviously not the consensus out there.
    - ShinTakuya 7y ago
      I guess the core of my argument is that none of these features need to be used. It's very easy to write basic scripts in Rust at least in my experience. Maybe you might encounter difficulty with the borrow checker occasionally, once in a blue moon now that non lexical lifetimes are a thing. Most of the other disadvantages also apply to Swift. Either way, people will find a way to justify their preference. The people in question liked Swift, and there's nothing wrong with that.
pjmlp 7y ago
Julia would have been the obvious choice, if Chris Latter wasn't leading the project, most likely.
- ShinTakuya 7y ago
  Probably, yes. My point is if they wanted a general purpose high performance multi-paradigm language like Swift. But in general I think Julia would have been a better choice, so I agree.
- LolWolf 7y ago
  Imo, Julia should’ve been the choice; I have never heard a single researcher use Swift for anything other than iOS coding (I certainly never have). But we will see how this plays out, I guess.
yAak 7y ago
Their reasoning: "We love Rust, but it has a steep learning curve that may exclude data scientists and other non-expert programmers who frequently use TensorFlow." [1] (I can't comment on that because I don't know Rust nor am I a data scientist!) [1] https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...
- ShinTakuya 7y ago
  Yeah it just sounds like a cop out to me, Swift's learning curve is equally steep to Rust in my experience. But as mentioned elsewhere, Julia would probably have been the best fit.

I don't want to be that guy, but if they were going with a heavy handed language anyway, why not Rust? It has a good multiplatform support and most of the same benefits of Swift.

TACIXAT 7y ago

The article addresses this. Data scientists probably don't want to manage memory.

ShinTakuya 7y ago
But that's not what you do in Rust? That's more of a C++ thing. I think you'd be surprised, Rust is much more similar to Swift than you'd think. The biggest layer of complexity is fighting with the borrow checker in some cases, but that only really comes into play when you want to write something concurrent.
- simias 7y ago
  I love Rust and I don't know much about data science but from my understanding many data scientists are not hardcore programmers it the same way that many programmers are not necessarily great at sysadmin. It's a tool, but it's not really the core of their job. In particular they mention Python being very popular in these circles. Switching from garbage collected and dynamically typed to manual memory management + static typing + borrow checker + trait-based generics is going to be a deep dive for these people. Maybe they'd end up better off in the end though, who knows. I personally think that dynamic typing and GCs are overrated and their benefits overstated but that's obviously not the consensus out there.
  - ShinTakuya 7y ago
    I guess the core of my argument is that none of these features need to be used. It's very easy to write basic scripts in Rust at least in my experience. Maybe you might encounter difficulty with the borrow checker occasionally, once in a blue moon now that non lexical lifetimes are a thing. Most of the other disadvantages also apply to Swift. Either way, people will find a way to justify their preference. The people in question liked Swift, and there's nothing wrong with that.

pjmlp 7y ago

Julia would have been the obvious choice, if Chris Latter wasn't leading the project, most likely.

ShinTakuya 7y ago
Probably, yes. My point is if they wanted a general purpose high performance multi-paradigm language like Swift. But in general I think Julia would have been a better choice, so I agree.
LolWolf 7y ago
Imo, Julia should’ve been the choice; I have never heard a single researcher use Swift for anything other than iOS coding (I certainly never have). But we will see how this plays out, I guess.

yAak 7y ago

Their reasoning: "We love Rust, but it has a steep learning curve that may exclude data scientists and other non-expert programmers who frequently use TensorFlow." [1] (I can't comment on that because I don't know Rust nor am I a data scientist!) [1] https://github.com/tensorflow/swift/blob/master/docs/WhySwiftForTensorFlow.md https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

ShinTakuya 7y ago
Yeah it just sounds like a cop out to me, Swift's learning curve is equally steep to Rust in my experience. But as mentioned elsewhere, Julia would probably have been the best fit.