4 ms·

Oh man. I feel like this is a really big deal. I've been wondering what might move data scientists to Rust. Outside working through rustlings and trying new pro

by tomrod 3y ago

Oh man. I feel like this is a really big deal. I've been wondering what might move data scientists to Rust. Outside working through rustlings and trying new projects in Rust, I wonder if having this available will be it.

spenczar5 3y ago
I agree. Two years ago, I tried writing data-intensive components for Python as rust extension modules. It was painful, tedious, and confusing. I came back to it for a second try a month ago, and was blown away. PyO3 and maturin (especially maturin) are stunningly straightforward. I actually find maturin easier to use than “normal” Python packaging tools, to the extent such a thing even exists. I really hope we will see a move towards rust, and away from extension modules written in C/C++/Fortran, just because the development experience is so much more approachable. Which is not something I thought I would say about Rust!
- tomrod 3y ago
  You've convinced me. I've been waiting to see when Julia or Rust would be able to start encroaching on Python's production lockup. Time to deep dive!
  - deleted 3y ago
    [deleted]
- locuscoeruleus 3y ago
  How can I effectively approach extending Python with Rust? I encountered some challenges while attempting to translate Python objects to Rust. My intuition suggests that it's more straightforward to work with arrays or dictionaries of primitive types. Could you share your approach and perhaps point me to some helpful examples or resources for better understanding?
DannyBee 3y ago
"I've been wondering what might move data scientists to Rust" I mean, writ large, the answer is "The availability of the ecosystem they need to use daily in Rust, without having to rewrite it themselves." That is more than just a torch replacement, so this won't do it for data scientists, even if Python is ... painful in a lot of ways to productionize or even use. Maybe it'll get some started on that ecosystem, though, so that a few years from now you see larger movement.
- appplication 3y ago
  More than the ecosystem, it’s the speed and flexibility in prototyping python offers. I do not see rust becoming a replacement for that. The uncomfortable fact is that you really don’t need thread safety or static typing to prototype and build models effectively.
- ElectricalUnion 3y ago
  I guess the answer is when the ecosystem stops being composed of mostly experimentation, training and prototyping (data scientists) and turns into deployment and upkeep (ops) of said systems. Prototyping and training doesn't pay the bills. (unless you're Hugging Face, lol)
tayo42 3y ago
id imagine repl, junpyter notebooks are pretty useful and not doable in rust atm
- tomrod 3y ago
  Rust in Jupyter Notebooks: https://users.rust-lang.org/t/getting-started-with-rust-jupyter-notebooks/39004 https://users.rust-lang.org/t/getting-started-with-rust-jupy... REPLit for Rust: https://replit.com/languages/rust https://replit.com/languages/rust For general REPL and rust appears there are a few options. I don't think getting rid of Python completely will happen. But current approaches _typically_ looks something like: - Jupyter Notebook for custom parts of EDA - Jupyter Notebook for testing new libraries or learning new methods - Pipeline (replaceable with Rust) for standard EDA - Pipeline (replaceable with Rust) for data quality - Application/pipeline for product development
  - tayo42 3y ago
    hmm ill look later, i thought they needed some compiler work done and miri to do it
AlchemistCamp 3y ago
> I've been wondering what might move data scientists to Rust. I think dynamic typing is the missing piece. Rust's safety guarantees are great and I like the language, but the type system is a barrier for learners, especially people who aren't full-time devs. Ease of experimentation and flexibility are key for this use case.
- CharlesW 3y ago
  > Rust's safety guarantees are great and I like the language, but the type system is a barrier for learners, especially people who aren't full-time devs. This surprises me. Hasn't everyone working with data (even at an "enthusiast" level) had to understand data types in the context of databases?
  - rirze 3y ago
    You underestimate the gusto of data engineers/scientists to just assume types.
  - spenczar5 3y ago
    Yes, but Rust’s type system is waaaaay more sophisticated than your typical SQL database. Talk about “generic associated types” and you can see people start to shrink back in fear. Plus, a surprisingly enormous fraction of the NoSQL hysteria was that “you don’t even need a schema!”
    - josephg 3y ago
      > Plus, a surprisingly enormous fraction of the NoSQL hysteria was that “you don’t even need a schema!” The problem with this is that you have a schema regardless. In "schemaless" systems, you still have a schema. You just don't have it written down anywhere. And because its not written down, the database doesn't enforce your schema. So its very common for nosql databases to have records with missing fields or subtly corrupted data. That said, there's a reason why nosql became popular. I think a large part of it is that SQL databases are too inflexible. You have to define the entire schema ahead of time, and schema evolution is way too difficult. When I'm writing software, I don't define all of my columns ahead of time. I want to add and change stuff as I go. I wish databases were more flexible. Like, let me just add arbitrary extra fields to my records. Let the database recommend promoting a dynamic field to a static field. ("Hey, all your records have a name: string field. Wanna make that required?"). I love programming languages with similar features. I love typescript for prototyping because I can start with the type any (or wildcard fields in my interfaces - like [k: string]: any). And then I can formalize my types later when I understand my software better. I don't think schemas are a mistake for beginners. I think the opposite - they're amazing guard rails. But I agree with other commenters here. Rust's types include information about ownership, lifetime, containment (Box / Rc), traits and the stored data type all in one go. Its terrifying to beginners and exhausting for experts to use. I've been writing rust for years, and the Future trait still scares me.
deleted 3y ago
[deleted]
huac 3y ago
I sense that most folks will end up using this via a Python wrapper, if at all, much like how HF has Transformers written in Rust but with a Python wrapper. This library is targeting production, a much smaller subset of engineers. See the 'why candle' section: https://github.com/huggingface/candle#why-candle https://github.com/huggingface/candle#why-candle. So you could use PyTorch to build models and Candle to serve them.
freilanzer 3y ago
> I've been wondering what might move data scientists to Rust. If they didn't migrate to Julia they certainly won't migrate to Rust.
- tomrod 3y ago
  As someone who has made that choice in this context, Rust is low-level but an increasing part of the stack, and Julia always had weird edge cases for me.
alex_lav 3y ago
> I've been wondering what might move data scientists to Rust. The two things that keep Python as the incumbent in this space is A.) It gets out of the way, sometimes to a fault, such that you can kinda write it without knowing what you're doing. This is a feature for most people, not a bug. And B.) All the math/science libraries that already exist for it. You can solve B, but until you solve A, Python stays put I think.
- jononor 3y ago
  And C) it is taught at every University that teaches ML/DS. I think unseating Python as the lingua franca will takes as long as it has taken to unseat MATLAB in engineering. 20+ years... Of course other things will also exist, and all languages will have decent ML support (especially for inference).
jeroenhd 3y ago
I tried to do some data analysis in Rust but I came back to Python quickly. There are Numpy alternatives for most features but they're all scarcely documented, not entirely compatible, or are missing methods and implementations that Numpy readily provides. With intensive Python processing being mostly C anyway, most data processing doesn't really benefit much from a Rust implementation. The actual native code implementation can probably be a lot better if that part switches over to Rust, with all of Rust's safeties and guarantees, but I don't think data science is going to switch to Rust for gluing together their actual calculations any time soon.

by tomrod 3y ago

spenczar5 3y ago

I agree. Two years ago, I tried writing data-intensive components for Python as rust extension modules. It was painful, tedious, and confusing. I came back to it for a second try a month ago, and was blown away. PyO3 and maturin (especially maturin) are stunningly straightforward. I actually find maturin easier to use than “normal” Python packaging tools, to the extent such a thing even exists. I really hope we will see a move towards rust, and away from extension modules written in C/C++/Fortran, just because the development experience is so much more approachable. Which is not something I thought I would say about Rust!

tomrod 3y ago
You've convinced me. I've been waiting to see when Julia or Rust would be able to start encroaching on Python's production lockup. Time to deep dive!
- deleted 3y ago
  [deleted]
locuscoeruleus 3y ago
How can I effectively approach extending Python with Rust? I encountered some challenges while attempting to translate Python objects to Rust. My intuition suggests that it's more straightforward to work with arrays or dictionaries of primitive types. Could you share your approach and perhaps point me to some helpful examples or resources for better understanding?

DannyBee 3y ago

"I've been wondering what might move data scientists to Rust" I mean, writ large, the answer is "The availability of the ecosystem they need to use daily in Rust, without having to rewrite it themselves." That is more than just a torch replacement, so this won't do it for data scientists, even if Python is ... painful in a lot of ways to productionize or even use. Maybe it'll get some started on that ecosystem, though, so that a few years from now you see larger movement.

appplication 3y ago
More than the ecosystem, it’s the speed and flexibility in prototyping python offers. I do not see rust becoming a replacement for that. The uncomfortable fact is that you really don’t need thread safety or static typing to prototype and build models effectively.
ElectricalUnion 3y ago
I guess the answer is when the ecosystem stops being composed of mostly experimentation, training and prototyping (data scientists) and turns into deployment and upkeep (ops) of said systems. Prototyping and training doesn't pay the bills. (unless you're Hugging Face, lol)

tayo42 3y ago

id imagine repl, junpyter notebooks are pretty useful and not doable in rust atm

tomrod 3y ago
Rust in Jupyter Notebooks: https://users.rust-lang.org/t/getting-started-with-rust-jupyter-notebooks/39004 https://users.rust-lang.org/t/getting-started-with-rust-jupy... REPLit for Rust: https://replit.com/languages/rust https://replit.com/languages/rust For general REPL and rust appears there are a few options. I don't think getting rid of Python completely will happen. But current approaches _typically_ looks something like: - Jupyter Notebook for custom parts of EDA - Jupyter Notebook for testing new libraries or learning new methods - Pipeline (replaceable with Rust) for standard EDA - Pipeline (replaceable with Rust) for data quality - Application/pipeline for product development
- tayo42 3y ago
  hmm ill look later, i thought they needed some compiler work done and miri to do it

AlchemistCamp 3y ago

> I've been wondering what might move data scientists to Rust. I think dynamic typing is the missing piece. Rust's safety guarantees are great and I like the language, but the type system is a barrier for learners, especially people who aren't full-time devs. Ease of experimentation and flexibility are key for this use case.

CharlesW 3y ago
> Rust's safety guarantees are great and I like the language, but the type system is a barrier for learners, especially people who aren't full-time devs. This surprises me. Hasn't everyone working with data (even at an "enthusiast" level) had to understand data types in the context of databases?
- rirze 3y ago
  You underestimate the gusto of data engineers/scientists to just assume types.
- spenczar5 3y ago
  Yes, but Rust’s type system is waaaaay more sophisticated than your typical SQL database. Talk about “generic associated types” and you can see people start to shrink back in fear. Plus, a surprisingly enormous fraction of the NoSQL hysteria was that “you don’t even need a schema!”
  - josephg 3y ago
    > Plus, a surprisingly enormous fraction of the NoSQL hysteria was that “you don’t even need a schema!” The problem with this is that you have a schema regardless. In "schemaless" systems, you still have a schema. You just don't have it written down anywhere. And because its not written down, the database doesn't enforce your schema. So its very common for nosql databases to have records with missing fields or subtly corrupted data. That said, there's a reason why nosql became popular. I think a large part of it is that SQL databases are too inflexible. You have to define the entire schema ahead of time, and schema evolution is way too difficult. When I'm writing software, I don't define all of my columns ahead of time. I want to add and change stuff as I go. I wish databases were more flexible. Like, let me just add arbitrary extra fields to my records. Let the database recommend promoting a dynamic field to a static field. ("Hey, all your records have a name: string field. Wanna make that required?"). I love programming languages with similar features. I love typescript for prototyping because I can start with the type any (or wildcard fields in my interfaces - like [k: string]: any). And then I can formalize my types later when I understand my software better. I don't think schemas are a mistake for beginners. I think the opposite - they're amazing guard rails. But I agree with other commenters here. Rust's types include information about ownership, lifetime, containment (Box / Rc), traits and the stored data type all in one go. Its terrifying to beginners and exhausting for experts to use. I've been writing rust for years, and the Future trait still scares me.

deleted 3y ago

[deleted]

huac 3y ago

I sense that most folks will end up using this via a Python wrapper, if at all, much like how HF has Transformers written in Rust but with a Python wrapper. This library is targeting production, a much smaller subset of engineers. See the 'why candle' section: https://github.com/huggingface/candle#why-candle https://github.com/huggingface/candle#why-candle. So you could use PyTorch to build models and Candle to serve them.

freilanzer 3y ago

> I've been wondering what might move data scientists to Rust. If they didn't migrate to Julia they certainly won't migrate to Rust.

tomrod 3y ago
As someone who has made that choice in this context, Rust is low-level but an increasing part of the stack, and Julia always had weird edge cases for me.

alex_lav 3y ago

> I've been wondering what might move data scientists to Rust. The two things that keep Python as the incumbent in this space is A.) It gets out of the way, sometimes to a fault, such that you can kinda write it without knowing what you're doing. This is a feature for most people, not a bug. And B.) All the math/science libraries that already exist for it. You can solve B, but until you solve A, Python stays put I think.

jononor 3y ago
And C) it is taught at every University that teaches ML/DS. I think unseating Python as the lingua franca will takes as long as it has taken to unseat MATLAB in engineering. 20+ years... Of course other things will also exist, and all languages will have decent ML support (especially for inference).

jeroenhd 3y ago

I tried to do some data analysis in Rust but I came back to Python quickly. There are Numpy alternatives for most features but they're all scarcely documented, not entirely compatible, or are missing methods and implementations that Numpy readily provides. With intensive Python processing being mostly C anyway, most data processing doesn't really benefit much from a Rust implementation. The actual native code implementation can probably be a lot better if that part switches over to Rust, with all of Rust's safeties and guarantees, but I don't think data science is going to switch to Rust for gluing together their actual calculations any time soon.