11 ms·

I've had a few Rust lovers come and mention this project to me recently. None of them had any data science or ML experience. None of them knew that Python is ju

I've had a few Rust lovers come and mention this project to me recently. None of them had any data science or ML experience. None of them knew that Python is just used to define the high level architecture. At the same time, comparatively tedious languages like Rust will never attract data science practitioners. They don't care about the kind of safety it brings, they don't care about improving performance in a component that's idle 99% of the time. The bulk of the load in an DL workflow is CUDA code and sits on the GPU. Even the intermediate libraries like cublas would only see marginal-to-none benefits of being reimplemented in rust. This is a cool project, but it has no chance to displace or even complement Python in the data science space.

wokwokwok 7y ago
> comparatively tedious languages like Rust will never attract data science practitioners. Well, fast.ai is using swift now. ... I think it's fair to say 'never say never'. You're probably right, rust isn't really the sweet spot for this stuff, but its also a case that python has some down sides that are pretty severe, and well acknowledged.
- melling 7y ago
  I wouldn’t call Swift a tedious language. With type inference, immutability, etc, Swift is far from tedious: http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=strings http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=stri... http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dictionaries http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dict... It’s not quite as nice as Python but it’s an enjoyable language.
  - frutiger 7y ago
    Rust has those too, GGGP still considered it tedious.
    - antisemiotic 7y ago
      I think the tedious part would be the borrow checker. Also, Rust doesn't have top-level type inference (by design).
      - skohan 7y ago
        Yeah there is some tedium in general with Rust syntax. Semicolons, for example, feel old fashioned, and there's a lot of verbosity in things like unwrapping. It's a fine language and I like working with it, but there's a lot of details involved in Rust development which don't make sense for data scientists to worry about.
  - wokwokwok 7y ago
    > They don't care about the kind of safety it brings, they don't care about improving performance in a component that's idle 99% of the time. https://www.fast.ai/2019/03/06/fastai-swift/ https://www.fast.ai/2019/03/06/fastai-swift/: > Because Swift for TensorFlow is the first serious effort I’ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance. > But Python is not designed to be fast, and it is not designed to be safe. Instead, it is designed to be easy, and flexible. To work around the performance problems of using “pure Python” code, we instead have to use libraries written in other languages (generally C and C++), like numpy, PyTorch, and TensorFlow, which provide Python wrappers. To work around the problem of a lack of type safety, recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide. ie. My point: OP's point is categorically false. ...not that swift is tedious. I <3 swift.
    - kuzehanka 7y ago
      ...But fast.ai is a Python library. Partially written in swift. Validating the original point that nothing will replace python for DL applications any time soon but middleware will continue to be implemented in c++/rust/swift/whatever you fancy. S4TF isn't the first and certainly not the last end to end non-python DL stack. It might be worth highlighting as an example if it ever reaches mindshare above the noise floor amongst those stacks.
      - wokwokwok 7y ago
        > Our hope is that we’ll be able to use Swift to write every layer of the deep learning stack, from the highest level network abstractions all the way down to the lowest level RNN cell implementation. There would be many benefits to doing this... Well, the tldr: you’re wrong. The more approachable reading: python isn’t going anywhere, but people are looking at other things for more than just low level implementations with a python wrapper. ...it’s early days yet, who knows where things will go... but maybe do a bit more reading and have an open mind? There’s more to life than python.
  - skohan 7y ago
    Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler which is giving me more correctness guarantees than Python is capable of. IMO Swift strikes the best balance between strictness and productivity of any language I've worked with.
    - ImNotTheNSA 7y ago
      > Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler boy do I have a continent full of python developers to introduce you to... “python - by any means necessary” is their motto. But in all seriousness, there are a lot of people (where I work) who started with python and have been daily driving it for so long that any other language is too tedious to get started with. Even if it means writing unreadable, hacky python, python still wins out for them. I suspect there are a lot of similar people in data science.
- chillee 7y ago
  Just because fast.ai has some investment in Swift does not mean that S4TF has attracted mind share. The bulk of fast.ai is still taught on Pytorch.
  - wokwokwok 7y ago
    The parent comment literally said data science practitioners don't care about speed or safety because the GPU is where all the real work happens; that's false, I've provided an example of it being false from a respected party. What do you want me to say? eh, I give up. Believe whatever you want to believe.
    - chillee 7y ago
      I'm not saying that no data science practitioners care about speed and safety, and its easy for me to come up with cases where they should/do care. My point is that even fast.ai still views S4TF as somewhat niche, and that data science practitioners as a whole still don't care.
      - MiroF 7y ago
        I am a practitioner, I care, but everyone on this thread seems to be distracted by the red herring of speed and efficiency. None of these languages are going to be speedier in the GPU. But python has serious design problems that manifest itself when developing a large project. You can only go so far with dynamic typing
xxxpupugo 7y ago
CUDA is an important part of the story. I think the industry is moving to 'MLIR' solution (Yes, there is a Google project called exactly that, but I am referring to the general idea here), where the network is defined and trained in one place, then the weights are exported, delegated to optimized runtime to be executed. If such trend furthers down, then there will be very little reason to replace Python as the glue layer here. Instead it will become that everything is training in Python -> exported to shared format -> executed in optimized runtime, kind of flow. Rust's opportunity could be to replace C++ in this case. But do mind that this is also a competitive business, where the computation is pushed further down to the hardware implementations, like TPUv1 and T4 chips etc.
- skohan 7y ago
  Personally I hope for alternatives because I don't find Python that nice to work with compared to other languages. It's not awful, but I really miss having type and nullability errors detected by the compiler and reported to me with meaningful error messages. Also there are a few weird things with the Python workflow, like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management. It's a bit like the story with imports in Javascript: those problems were never really solved, and the popular solutions are just sort of bolted on to the language. It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for.
  - ImNotTheNSA 7y ago
    > like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management. Not to mention, this problem seems to be getting worse, not better. People are moving off of python 2.7, which was kind of the de-facto LTS release of python... leaving (currently) no LTS version of python and no clear path for the community to establish a new LTS version that the community will still support — there are so many releases with so many breaking changes in python 3 within the last few years that there is seemingly no consensus and no way to compromise. > It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for. This is becoming more and more clear with every release of python IMO. The language is evolving too quickly for it to be used on large developments, but it’s still being used for that. We have an entire test framework and libraries for high performance embedded systems level testing which is written entirely in python. The amount of high speed operations (timing tests, measurements, etc) is very obviously overwhelming for the intention of the language and libraries, yet the company keeps pushing ahead with this stuff. In order to mitigate the issue, we are developing more high speed embedded systems to offload the work from the test framework and report measurements to the framework. I think it’s quickly becoming extremely expensive and will only become more expensive — the framework is extremely “pythonic” to the point of being unreadable, using a number of hacks to break through the python interpreter. Jobs much better allocated to readable C++ libraries are being implemented in unreadable python spaghetti code with no clear architecture - just quick-and-dirty whatever-it-takes python. I love python but I think it’s a quick-and-dirty language for a reason. What python does well cannot be beat by other languages (for example, prototyping), but I think it is often misused, since people can get something up and running quickly and cleanly in python, but it eventually has diminishing (and even negative) returns.
pjmlp 7y ago
Rust might not be it. But AOT/JIT compiled languages that can naturally talk to the GPGPU, without 2nd language syndrome, like Julia, Swift, Java and .NET will certainly be more attractive to data science practitioners. I can already envision those life science guys that migrate to VB.NET when they have outgrown their Excel/VBA code, to start playing with ML.NET.
- kuzehanka 7y ago
  Python already gets JIT compiled to CUDA[1] and there's an entire funded ecosystem built around python+gpgpu called RAPIDS[2] which is the future of the ML space by most indicators. I don't see any other language even making a dent in the Python ecosystem without some kind of new killer feature that can't be quickly replicated in Python. [1] https://numba.pydata.org https://numba.pydata.org [2] https://rapids.ai https://rapids.ai
  - disgruntledphd2 7y ago
    Thank you for the cite to rapids.ai, that looks extremely interesting :)
  - MiroF 7y ago
    Swift and static type checking and compiler analysis might be that language and feature combo.
  - hsaliak 7y ago
    You beat me to making this point. I don't see anything in the article's python code that the numba's jit decorator cannot handle. When numba works (it's rapidly improving), it's seriously impressive. For this particular case, you should be able to get really good performance without sacrificing readability. Also Jax - https://github.com/google/jax https://github.com/google/jax
- MiroF 7y ago
  Your last paragraph is my nightmare
skohan 7y ago
This is why I think Swift is a much better choice to replace or at least compliment Python than Rust. It has a modern, powerful type system and all the quality of life advantages which come with it, but it manages this with a lot more usability than Rust. A well written swift framework almost becomes a DSL for the problem domain, which is a great property for a data science tool to have.
- echelon 7y ago
  Swift is not fun on non-Mac platforms. It feels a lot like Google's Dart in terms of how it was positioned and advocated. Modern Rust isn't difficult to use. This is becoming a really tired meme from detractors. The compiler is incredibly helpful, non-lexical lifetimes are a thing, and unless you're doing a lot of sharing and parallelism, you can avoid many borrow checker problems until you learn RAII.
  - skohan 7y ago
    It's a fair criticism of Swift that it is not well supported across platforms. The story is getting better, but it is still miles behind Rust in this regard. I am a huge fan of Swift as a language, but I am very critical of the tooling. > Modern Rust isn't difficult to use. This is becoming a really tired meme from detractors. I beg to differ. I've been programming professionally for over a decade, and I have shipped projects in a variety of languages, and I can safely say that Rust has a steeper learning curve and requires more cognitive overhead to use than many other languages. I find it relatively nice to work with rust in spite of this because the tooling is so great, but it's undeniable that Rust has made tradeoffs which sacrifice ease of use in favor of safety and performance.
    - MiroF 7y ago
      The tooling for Swift 4 TF is not anywhere near satisfactory. I can't even seem to get it on my computer without installing XCode (and that's on an apple computer) I should be able to pull a docker image and have s4tf immediately at my fingertips
danielscrubs 7y ago
I am a data scientist and I care. The time when you could just do proof of concepts or a PowerPoint presentation is long behind us. So now we have to start to take it into production, which means we get the exact same problems as SE has always had. Iff Rust helps us take it into production we will use it. But it’s a lot of land to cover to reach Pythons libraries so I’m not holding my breath. That said, Pythons performance is slow even when shuffling to Numpy.
- kuzehanka 7y ago
  I must be missing something. Modern data science workloads involve fanning out data and code across dozens to hundreds of nodes. The bottlenecks, in order, are: inter-node comms, gpu/compute, on-disk shuffling, serialisation, pipeline starvation, and finally the runtime. Why worry about optimising the very top of the perf pyramid which will make the least difference? Why worry if you spent 1ms pushing data to numpy when that data just spent 2500ms on the wire? And why are you even pushing from python runtime to numpy instead of using arrow?
  - corndoge 7y ago
    Good lord, hopefully latency isn't 2.5 seconds!
    - sjwright 7y ago
      I can’t even. How could you ever get 2500 msec on transit? That’s like circling the globe ten times.
      - justinclift 7y ago
        Maybe a bunch of SSL cert exchanges through some very low bandwidth connections? ;) Still, it's more likely a figure used for exaggeration, for effect.
        deleted 7y ago
        [deleted]
Nullabillity 7y ago
I'm by no means a specialized data scientist, but I've done some (very surface-level) text crunching with both the TF/Numpy stack and Rust. To me, the nice thing about switching to Rust for that kind of stuff was that it dramatically raised the bar of what I could do before reaching for those hyper-optimized descriptive libraries. Want to calculate the levenshtein distances of the cross product of 100k strings? Sure, just load it into a Vec, find a levenshtein library on crates.io, and it'll probably be fast enough. Could it be done in Python? Sure, but with Rust I didn't have to think about how to do it in a viable amount of time. Does that mean that Rust is going to take over the DS world? Probably not in the short term, Rust currently can't compete with Python's DS ecosystem. But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it.
- smallnamespace 7y ago
  > But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it. The thing is, for anything performance intensive and scientific, you're almost guaranteed to find a Python binding. It has all these bindings because scientists are almost always writing either Python, C++, or Fortran (with a smattering of R or Octave on the side). Want to do linear algebra? NumPy is always there, otherwise you can go lower level: https://docs.scipy.org/doc/scipy/reference/linalg.blas.html https://docs.scipy.org/doc/scipy/reference/linalg.blas.html Old-school optimization? https://www.roguewave.com/sites/rw/files/attachments/PyIMSLStudioFeatures.pdf https://www.roguewave.com/sites/rw/files/attachments/PyIMSLS... Computer vision? https://pypi.org/project/opencv-python/ https://pypi.org/project/opencv-python/ In fact, I'd basically argue against using most language-native implementations of algorithms where performance is at stake, because most implementations don't have all the algorithmic optimizations.
  - danielscrubs 7y ago
    And they will cover a small part of what is found in research papers. Python has the best ecosystem, but Rust was made by a competent team so we will root for it.
echelon 7y ago
I think this project has immediate merits when it comes to productionizing small, sparse networks for running on the CPU. I do research and prototyping in Python, but I have to deploy on mobile devices. I was going to roll my own implementation, but now that this exists, it's something I'm going to look into.
- MiroF 7y ago
  Load the model from torch script? In C++? Don't see why Rust made this possible.
  - echelon 7y ago
    Ideally we'd have native Rust loading of tensorflow, pytorch, etc. models. I've hand-coded a few, but it was pretty monotonous.

wokwokwok 7y ago

> comparatively tedious languages like Rust will never attract data science practitioners. Well, fast.ai is using swift now. ... I think it's fair to say 'never say never'. You're probably right, rust isn't really the sweet spot for this stuff, but its also a case that python has some down sides that are pretty severe, and well acknowledged.

melling 7y ago
I wouldn’t call Swift a tedious language. With type inference, immutability, etc, Swift is far from tedious: http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=strings http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=stri... http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dictionaries http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dict... It’s not quite as nice as Python but it’s an enjoyable language.
- frutiger 7y ago
  Rust has those too, GGGP still considered it tedious.
  - antisemiotic 7y ago
    I think the tedious part would be the borrow checker. Also, Rust doesn't have top-level type inference (by design).
    - skohan 7y ago
      Yeah there is some tedium in general with Rust syntax. Semicolons, for example, feel old fashioned, and there's a lot of verbosity in things like unwrapping. It's a fine language and I like working with it, but there's a lot of details involved in Rust development which don't make sense for data scientists to worry about.
- wokwokwok 7y ago
  > They don't care about the kind of safety it brings, they don't care about improving performance in a component that's idle 99% of the time. https://www.fast.ai/2019/03/06/fastai-swift/ https://www.fast.ai/2019/03/06/fastai-swift/: > Because Swift for TensorFlow is the first serious effort I’ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance. > But Python is not designed to be fast, and it is not designed to be safe. Instead, it is designed to be easy, and flexible. To work around the performance problems of using “pure Python” code, we instead have to use libraries written in other languages (generally C and C++), like numpy, PyTorch, and TensorFlow, which provide Python wrappers. To work around the problem of a lack of type safety, recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide. ie. My point: OP's point is categorically false. ...not that swift is tedious. I <3 swift.
  - kuzehanka 7y ago
    ...But fast.ai is a Python library. Partially written in swift. Validating the original point that nothing will replace python for DL applications any time soon but middleware will continue to be implemented in c++/rust/swift/whatever you fancy. S4TF isn't the first and certainly not the last end to end non-python DL stack. It might be worth highlighting as an example if it ever reaches mindshare above the noise floor amongst those stacks.
    - wokwokwok 7y ago
      > Our hope is that we’ll be able to use Swift to write every layer of the deep learning stack, from the highest level network abstractions all the way down to the lowest level RNN cell implementation. There would be many benefits to doing this... Well, the tldr: you’re wrong. The more approachable reading: python isn’t going anywhere, but people are looking at other things for more than just low level implementations with a python wrapper. ...it’s early days yet, who knows where things will go... but maybe do a bit more reading and have an open mind? There’s more to life than python.
- skohan 7y ago
  Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler which is giving me more correctness guarantees than Python is capable of. IMO Swift strikes the best balance between strictness and productivity of any language I've worked with.
  - ImNotTheNSA 7y ago
    > Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler boy do I have a continent full of python developers to introduce you to... “python - by any means necessary” is their motto. But in all seriousness, there are a lot of people (where I work) who started with python and have been daily driving it for so long that any other language is too tedious to get started with. Even if it means writing unreadable, hacky python, python still wins out for them. I suspect there are a lot of similar people in data science.
chillee 7y ago
Just because fast.ai has some investment in Swift does not mean that S4TF has attracted mind share. The bulk of fast.ai is still taught on Pytorch.
- wokwokwok 7y ago
  The parent comment literally said data science practitioners don't care about speed or safety because the GPU is where all the real work happens; that's false, I've provided an example of it being false from a respected party. What do you want me to say? eh, I give up. Believe whatever you want to believe.
  - chillee 7y ago
    I'm not saying that no data science practitioners care about speed and safety, and its easy for me to come up with cases where they should/do care. My point is that even fast.ai still views S4TF as somewhat niche, and that data science practitioners as a whole still don't care.
    - MiroF 7y ago
      I am a practitioner, I care, but everyone on this thread seems to be distracted by the red herring of speed and efficiency. None of these languages are going to be speedier in the GPU. But python has serious design problems that manifest itself when developing a large project. You can only go so far with dynamic typing

xxxpupugo 7y ago

CUDA is an important part of the story. I think the industry is moving to 'MLIR' solution (Yes, there is a Google project called exactly that, but I am referring to the general idea here), where the network is defined and trained in one place, then the weights are exported, delegated to optimized runtime to be executed. If such trend furthers down, then there will be very little reason to replace Python as the glue layer here. Instead it will become that everything is training in Python -> exported to shared format -> executed in optimized runtime, kind of flow. Rust's opportunity could be to replace C++ in this case. But do mind that this is also a competitive business, where the computation is pushed further down to the hardware implementations, like TPUv1 and T4 chips etc.

skohan 7y ago
Personally I hope for alternatives because I don't find Python that nice to work with compared to other languages. It's not awful, but I really miss having type and nullability errors detected by the compiler and reported to me with meaningful error messages. Also there are a few weird things with the Python workflow, like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management. It's a bit like the story with imports in Javascript: those problems were never really solved, and the popular solutions are just sort of bolted on to the language. It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for.
- ImNotTheNSA 7y ago
  > like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management. Not to mention, this problem seems to be getting worse, not better. People are moving off of python 2.7, which was kind of the de-facto LTS release of python... leaving (currently) no LTS version of python and no clear path for the community to establish a new LTS version that the community will still support — there are so many releases with so many breaking changes in python 3 within the last few years that there is seemingly no consensus and no way to compromise. > It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for. This is becoming more and more clear with every release of python IMO. The language is evolving too quickly for it to be used on large developments, but it’s still being used for that. We have an entire test framework and libraries for high performance embedded systems level testing which is written entirely in python. The amount of high speed operations (timing tests, measurements, etc) is very obviously overwhelming for the intention of the language and libraries, yet the company keeps pushing ahead with this stuff. In order to mitigate the issue, we are developing more high speed embedded systems to offload the work from the test framework and report measurements to the framework. I think it’s quickly becoming extremely expensive and will only become more expensive — the framework is extremely “pythonic” to the point of being unreadable, using a number of hacks to break through the python interpreter. Jobs much better allocated to readable C++ libraries are being implemented in unreadable python spaghetti code with no clear architecture - just quick-and-dirty whatever-it-takes python. I love python but I think it’s a quick-and-dirty language for a reason. What python does well cannot be beat by other languages (for example, prototyping), but I think it is often misused, since people can get something up and running quickly and cleanly in python, but it eventually has diminishing (and even negative) returns.

pjmlp 7y ago

Rust might not be it. But AOT/JIT compiled languages that can naturally talk to the GPGPU, without 2nd language syndrome, like Julia, Swift, Java and .NET will certainly be more attractive to data science practitioners. I can already envision those life science guys that migrate to VB.NET when they have outgrown their Excel/VBA code, to start playing with ML.NET.

kuzehanka 7y ago
Python already gets JIT compiled to CUDA[1] and there's an entire funded ecosystem built around python+gpgpu called RAPIDS[2] which is the future of the ML space by most indicators. I don't see any other language even making a dent in the Python ecosystem without some kind of new killer feature that can't be quickly replicated in Python. [1] https://numba.pydata.org https://numba.pydata.org [2] https://rapids.ai https://rapids.ai
- disgruntledphd2 7y ago
  Thank you for the cite to rapids.ai, that looks extremely interesting :)
- MiroF 7y ago
  Swift and static type checking and compiler analysis might be that language and feature combo.
- hsaliak 7y ago
  You beat me to making this point. I don't see anything in the article's python code that the numba's jit decorator cannot handle. When numba works (it's rapidly improving), it's seriously impressive. For this particular case, you should be able to get really good performance without sacrificing readability. Also Jax - https://github.com/google/jax https://github.com/google/jax
MiroF 7y ago
Your last paragraph is my nightmare

skohan 7y ago

This is why I think Swift is a much better choice to replace or at least compliment Python than Rust. It has a modern, powerful type system and all the quality of life advantages which come with it, but it manages this with a lot more usability than Rust. A well written swift framework almost becomes a DSL for the problem domain, which is a great property for a data science tool to have.

echelon 7y ago
Swift is not fun on non-Mac platforms. It feels a lot like Google's Dart in terms of how it was positioned and advocated. Modern Rust isn't difficult to use. This is becoming a really tired meme from detractors. The compiler is incredibly helpful, non-lexical lifetimes are a thing, and unless you're doing a lot of sharing and parallelism, you can avoid many borrow checker problems until you learn RAII.
- skohan 7y ago
  It's a fair criticism of Swift that it is not well supported across platforms. The story is getting better, but it is still miles behind Rust in this regard. I am a huge fan of Swift as a language, but I am very critical of the tooling. > Modern Rust isn't difficult to use. This is becoming a really tired meme from detractors. I beg to differ. I've been programming professionally for over a decade, and I have shipped projects in a variety of languages, and I can safely say that Rust has a steeper learning curve and requires more cognitive overhead to use than many other languages. I find it relatively nice to work with rust in spite of this because the tooling is so great, but it's undeniable that Rust has made tradeoffs which sacrifice ease of use in favor of safety and performance.
  - MiroF 7y ago
    The tooling for Swift 4 TF is not anywhere near satisfactory. I can't even seem to get it on my computer without installing XCode (and that's on an apple computer) I should be able to pull a docker image and have s4tf immediately at my fingertips

danielscrubs 7y ago

I am a data scientist and I care. The time when you could just do proof of concepts or a PowerPoint presentation is long behind us. So now we have to start to take it into production, which means we get the exact same problems as SE has always had. Iff Rust helps us take it into production we will use it. But it’s a lot of land to cover to reach Pythons libraries so I’m not holding my breath. That said, Pythons performance is slow even when shuffling to Numpy.

kuzehanka 7y ago
I must be missing something. Modern data science workloads involve fanning out data and code across dozens to hundreds of nodes. The bottlenecks, in order, are: inter-node comms, gpu/compute, on-disk shuffling, serialisation, pipeline starvation, and finally the runtime. Why worry about optimising the very top of the perf pyramid which will make the least difference? Why worry if you spent 1ms pushing data to numpy when that data just spent 2500ms on the wire? And why are you even pushing from python runtime to numpy instead of using arrow?
- corndoge 7y ago
  Good lord, hopefully latency isn't 2.5 seconds!
  - sjwright 7y ago
    I can’t even. How could you ever get 2500 msec on transit? That’s like circling the globe ten times.
    - justinclift 7y ago
      Maybe a bunch of SSL cert exchanges through some very low bandwidth connections? ;) Still, it's more likely a figure used for exaggeration, for effect.
      - deleted 7y ago
        [deleted]

Nullabillity 7y ago

I'm by no means a specialized data scientist, but I've done some (very surface-level) text crunching with both the TF/Numpy stack and Rust. To me, the nice thing about switching to Rust for that kind of stuff was that it dramatically raised the bar of what I could do before reaching for those hyper-optimized descriptive libraries. Want to calculate the levenshtein distances of the cross product of 100k strings? Sure, just load it into a Vec, find a levenshtein library on crates.io, and it'll probably be fast enough. Could it be done in Python? Sure, but with Rust I didn't have to think about how to do it in a viable amount of time. Does that mean that Rust is going to take over the DS world? Probably not in the short term, Rust currently can't compete with Python's DS ecosystem. But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it.

smallnamespace 7y ago
> But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it. The thing is, for anything performance intensive and scientific, you're almost guaranteed to find a Python binding. It has all these bindings because scientists are almost always writing either Python, C++, or Fortran (with a smattering of R or Octave on the side). Want to do linear algebra? NumPy is always there, otherwise you can go lower level: https://docs.scipy.org/doc/scipy/reference/linalg.blas.html https://docs.scipy.org/doc/scipy/reference/linalg.blas.html Old-school optimization? https://www.roguewave.com/sites/rw/files/attachments/PyIMSLStudioFeatures.pdf https://www.roguewave.com/sites/rw/files/attachments/PyIMSLS... Computer vision? https://pypi.org/project/opencv-python/ https://pypi.org/project/opencv-python/ In fact, I'd basically argue against using most language-native implementations of algorithms where performance is at stake, because most implementations don't have all the algorithmic optimizations.
- danielscrubs 7y ago
  And they will cover a small part of what is found in research papers. Python has the best ecosystem, but Rust was made by a competent team so we will root for it.

echelon 7y ago

I think this project has immediate merits when it comes to productionizing small, sparse networks for running on the CPU. I do research and prototyping in Python, but I have to deploy on mobile devices. I was going to roll my own implementation, but now that this exists, it's something I'm going to look into.

MiroF 7y ago
Load the model from torch script? In C++? Don't see why Rust made this possible.
- echelon 7y ago
  Ideally we'd have native Rust loading of tensorflow, pytorch, etc. models. I've hand-coded a few, but it was pretty monotonous.