The spreadsheet that won't crash
You are staring at a CSV file that is three gigabytes. Your Python script loads it into a DataFrame, runs a groupby, and then your laptop fan sounds like a jet engine. The script finishes in four minutes. You run it again with a slightly different filter. Four minutes. You realize the bottleneck is not your algorithm. It is the memory management and the global interpreter lock fighting over every single row. You want speed without rewriting your entire workflow in C. That is the exact moment Rust stops being a curiosity and starts being a tool.
What "good for data science" actually means
Data science in Rust does not look like data science in Python. Python gives you a fully furnished kitchen. You grab a pan, turn on the stove, and start cooking. Rust gives you a raw forge. You have to build the pan, strike the flint, and manage the airflow. The tradeoff is control. When you write a data pipeline in Rust, you decide exactly how memory is allocated, how threads split the work, and when data gets copied. The language enforces those decisions at compile time. If your code tries to read a column while another thread is mutating it, the compiler refuses to build. If you accidentally drop a reference to your dataset before the calculation finishes, the build fails. This eliminates an entire class of runtime crashes that plague large data workloads.
The ecosystem is younger. You will not find a direct replacement for every pandas method or every scikit-learn estimator. The community focuses on building primitives that are fast, safe, and composable. You get ndarray for multi-dimensional arrays, polars for high-performance DataFrame operations, and arrow for zero-copy data interchange. You piece them together instead of downloading a monolithic library. The convention in the Rust data community is to prefer columnar formats. Row-by-row processing destroys CPU cache performance. Columnar storage lets the processor stream contiguous blocks of numbers through the arithmetic logic unit without jumping around in memory.
Build your data structures around contiguous memory. Cache locality beats clever algorithms every time.
A minimal data pipeline in Rust
Here is a straightforward aggregation task. We load a flat list of numbers, split them into chunks, and compute the average for each chunk without allocating extra memory for intermediate results.
/// Computes the average of each chunk in a slice without extra allocations.
fn chunk_averages(data: &[f64], chunk_size: usize) -> Vec<f64> {
let mut results = Vec::with_capacity(data.len() / chunk_size + 1);
// Pre-allocating the output vector prevents repeated reallocations during the loop.
for chunk in data.chunks(chunk_size) {
let sum: f64 = chunk.iter().sum();
let avg = sum / chunk.len() as f64;
results.push(avg);
}
results
}
fn main() {
let dataset = vec![10.0, 20.0, 30.0, 40.0, 50.0, 60.0];
let averages = chunk_averages(&dataset, 2);
println!("{:?}", averages); // Outputs: [15.0, 35.0, 55.0]
}
Walking through the execution
The function takes a slice &[f64]. A slice is a view into existing memory. It does not own the data, so passing it costs zero allocations. The chunks iterator hands us a window into the original array without copying the numbers. We sum the window, divide by the length, and push the result. The Vec::with_capacity call tells the allocator exactly how much space to reserve upfront. Without it, the vector would start small, fill up, allocate a larger block, copy the old data over, and repeat. That reallocation pattern destroys cache performance on large datasets. By the time the loop finishes, we have our averages and the original dataset is untouched. The compiler guarantees that chunk_averages cannot accidentally mutate data because the signature uses an immutable reference.
Notice the type annotation on sum. The compiler needs to know whether you want an integer sum or a floating point sum. Rust does not guess. You tell it explicitly. This prevents silent precision loss when you mix i32 and f64 columns in a real dataset. The iterator chain is lazy until you call sum(). The compiler inlines the loop and eliminates the iterator overhead entirely. You get the readability of a high-level chain with the performance of a hand-written for loop.
Trust the compiler to optimize the loop. Write code that expresses intent, not micro-optimizations.
Realistic scenario: bridging Python and Rust
Most data scientists live in Python. You do not need to abandon Jupyter notebooks to benefit from Rust. The standard pattern is to write the heavy lifting in Rust and expose it to Python using pyo3. This keeps your exploratory workflow in Python while offloading the bottleneck to compiled code.
use pyo3::prelude::*;
/// Multiplies two matrices using a simple nested loop.
/// In production, you would delegate to ndarray or a BLAS backend.
#[pyfunction]
fn multiply_matrices(a: Vec<Vec<f64>>, b: Vec<Vec<f64>>) -> PyResult<Vec<Vec<f64>>> {
let rows_a = a.len();
let cols_b = b[0].len();
let cols_a = a[0].len();
// Validate dimensions before starting the computation.
if b.len() != cols_a {
return Err(PyErr::new::<pyo3::exceptions::PyValueError, _>(
"Matrix dimensions do not align for multiplication."
));
}
let mut result = vec![vec![0.0; cols_b]; rows_a];
for i in 0..rows_a {
for j in 0..cols_b {
for k in 0..cols_a {
result[i][j] += a[i][k] * b[k][j];
}
}
}
Ok(result)
}
/// Defines the Python module containing our Rust functions.
#[pymodule]
fn fast_ops(m: &Bound<'_, PyModule>) -> PyResult<()> {
m.add_function(wrap_pyfunction!(multiply_matrices, m)?)?;
Ok(())
}
You compile this with cargo build --release, grab the generated shared library, and import it in Python like any other package. The GIL is released automatically during the heavy loops because pyo3 handles the boundary. Your Python code stays readable. Your Rust code stays fast. The community convention here is to keep the Rust module focused on pure computation. Do not mix I/O or complex Python object manipulation inside the hot path. Keep the boundary clean. Flatten your data before crossing the language barrier. Passing a Python list of lists into Rust means crossing the boundary dozens of times. Convert to a flat byte buffer or an Arrow array first. The performance gain comes from reducing serialization overhead, not from faster CPU instructions.
Keep the FFI boundary thin. Serialize once, compute many times.
Where the friction lives
The learning curve shows up in two places. The first is borrowing. You will try to mutate a DataFrame while holding a reference to one of its columns. The compiler stops you with E0502 (cannot borrow as mutable because it is also borrowed as immutable). This happens because Rust refuses to let you create a dangling reference. If you mutate the parent, the child reference becomes invalid. The fix is usually to clone the column before mutating the parent, or to restructure the code so the mutation happens first.
The second friction point is trait bounds. You will write a function that works on &[f64] and try to pass a Vec<f64> directly. The compiler rejects it with E0277 (trait bound not satisfied) or E0308 (mismatched types). Rust does not automatically dereference or coerce types the way Python does. You add an ampersand to borrow the vector, or you change the function signature to accept Into<Vec<f64>> if you want flexibility. The compiler messages are verbose for a reason. They point exactly to the line where the contract breaks. Read the first paragraph of the error. It tells you what the compiler expected and what it found.
Memory layout is another silent trap. Python DataFrames often store data in a row-major or object-heavy format. Rust arrays are contiguous blocks of memory. If you pass a Python list of lists into Rust, you are crossing the language boundary dozens of times. Flatten your data before the boundary. Use arrow or ndarray formats that map directly to contiguous memory. The performance gain comes from cache locality, not from faster CPU instructions.
You will also hit E0382 (use of moved value) when you try to reuse a dataset after passing it into a function that takes ownership. Data science code often chains transformations. Rust forces you to decide whether each step consumes the data or borrows it. Borrowing is almost always the right choice for pipelines. Ownership is for when you are building the final result.
Read the error message before searching the internet. The compiler already told you the exact fix.
When to reach for Rust, and when to stick with Python
Use Python for exploratory analysis when you are prototyping models, cleaning messy text, or iterating on visualizations. The ecosystem is mature, the syntax is forgiving, and the overhead is invisible during development. Use Rust for data processing pipelines when you are moving gigabytes of structured data, running fixed transformations at scale, or building a service that must handle concurrent requests without garbage collection pauses. Use Rust for custom machine learning kernels when you need deterministic memory usage, SIMD vectorization, or tight integration with hardware accelerators. Use Python bindings when you want to keep your team in a familiar notebook environment but need to replace a specific bottleneck with compiled code. Reach for established crates like polars or ndarray instead of rolling your own linear algebra unless you are implementing a novel algorithm. The community has already solved the cache alignment and thread pooling problems.
Pick the tool that matches the workload. Do not rewrite a five-line pandas script in Rust to prove a point. Rewrite the function that takes forty seconds to run.