Hacker News Reader

Comment by tomrod | Hacker News Reader

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.

View on HN

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!

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!

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?

"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.

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.

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)

> 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.

> 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?

You underestimate the gusto of data engineers/scientists to just assume types.

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!”

> 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.

There's a bit of general dev snobbery to assume that data scientists can't code, or don't want to learn to code, or are able to understand so many other things but not a compiled language or a static type system.

It's not about ability to code, willingness to learn, or ability to understand. It's about friction. When you're iterating quickly and you're thinking about complicated mathematics and ideas, a complicated type system just adds a ton of friction. This is especially annoying when you know what you're doing is correct but the type system is unsatisfied and demands proof.

the place in DL/ML where typing could be the most useful is to keep you from trying to multiply differently sized tensors together. So the irony is that the one place where typing WOULD help DL/ML, is the place where rust is weak in its typing system (dependent types and const generics)

I keep checking the progress on dfdx for this reason. It does what I (and, I assume from context, you) want: Provides static checking of tensor shapes. Which is fantastic. Not quite as much inference as I'd like but I love getting compile-time errors that I forgot to transpose before a matmul.

It depends on the generic_const_exprs feature which is still, to quote, "highly experimental":

https://github.com/rust-lang/rust/issues/76560

Definitely not for production use, but it gives a flavor for where things can head in the medium term, and it's .. it's nice. You could imagine future type support allowing even more inference for some intermediate shapes, of course, but even what it has now is really nice. Like this cute little convnet example:

https://github.com/coreylowman/dfdx/blob/main/examples/night...

A lot of science/engineering/ML/data analysis happens from hacking around with only a vague idea of what to expect. Appeasing a type checker simultaneously is an enormous blow to productivity. Obviously possible, but challenging to get into a flow state when you cannot quickly iterate on ideas.

I mean you can still hold data in hashmaps no?

Or even serde::Value(s)? Its not that everything has to be a type

If we're going to bypass the type system entirely then why are we using Rust at all? Might as well just use Python at this point

Who said entirely? I’ve used hashmaps prototyping my code, still used types in other areas, then converting dynamic maps to types too, Was just suggesting ways to handle types during prototyping

Not with an ownership model and lifetimes. Most of the scientists I know have not even dealt with parametric types.

It is not a barrier for learners. It is a barrier for people that just want to hack something together that works for one particular use-case.

Python is not popular because it is "easy" (far from it if you have to maintain it). But because it is easy to create executable code that does what you want, without having to have a background in coding.

The type system is certainly not a barrier, it’s actually rather straightforward unless I am missing something.

If you refer to lifetimes and borrow checker, those are different.

> 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.

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.

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.

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. So you could use PyTorch to build models and Candle to serve them.

> 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.

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).

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

Rust in Jupyter Notebooks: https://users.rust-lang.org/t/getting-started-with-rust-jupy...

REPLit for 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

hmm ill look later, i thought they needed some compiler work done and miri to do it

Reply on news.ycombinator.com