Live data from Hacker News

Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

datacrayon.com

1–10 of 30 posts

Re: Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

#4
I love Rust for systems dev, and I truly can't wait to read the article, because I can't imagine ever wanting to use it for exploratory data analysis, one-off stuff, or notebooks.

Why deal with the borrow checker and compilation just to plot something in a notebook? Python is kind of ugly IMO, but it seems much quicker for prototyping.

Re: Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

#6

I love Rust for systems dev, and I truly can't wait to read the article, because I can't imagine ever wanting to use it for exploratory data analysis, one-off stuff, or notebooks. Why deal with the borrow checker and compilation just to plot something in a notebook? Python is kind of ugly IMO, but it seems much quicker for prototyping.

Main reason is - you're already proficient with Rust and enjoy using it.

I don't think there's much borrow checker issues in data analysis code. You `.clone()` everywhere, and it's still going to fly fast.

Some benefits:

* static typing niceness: language server, typo catching, some types preventing human error here and there etc. * expressing some ideas in a much more robust way * best in class tooling like package manager, rustdoc * hitting some unexpected not strictly data-analysis requirement is never a blocker * you can reuse your code, compile to WASM and embed in a page * performance of auxiliary code is never an issue * unlike Python, you can send it to another person and expect it to work just like it did for you * if it turns out that the "one-off" has to become more complex and serious, you don't have to throw away everything and start rewriting it "in more serious way"

Re: Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

#7
Totally unrelated since I can't access the website, but one thing that I'd like to see in a typing system used in data analysis is to be able to see the dimension of the data structures used. For instance, to be able to tell at compile time if a matrix multiplication is going to crash due to dimension mismatch.

So far, in Python at least, at best I can tell that it's a float array, without specifying the dimension (for example 2d for a matrix) or better, specifying its dimension is (n,p) where n and p are both type variables.

Re: Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

#8

I love Rust for systems dev, and I truly can't wait to read the article, because I can't imagine ever wanting to use it for exploratory data analysis, one-off stuff, or notebooks. Why deal with the borrow checker and compilation just to plot something in a notebook? Python is kind of ugly IMO, but it seems much quicker for prototyping.

In my opinion, we need a statically typed contender to R, Python and Julia.

The use case is quite simple. Most data-oriented applications where you need linear algebra, probability theory, statistics do contain a significant amount of data pre-processing and business logic once extended to enter production. Here static typing is advantageous. Keeping the whole codebase in the same language is a significant advantage.

Furthemore, some statically typed languages do have typing features that are advantageous for data analysis. Think F# type providers or type systems where e.g. the shape of arrays is guaranteed to match at compile time.

The question is whether Rust is a good language for this, or we need something more like OCaml or F#. All these languages pop up in job offers for quantitative analysis, insurance risk modeling, etc. So there seems to be a demand.

Re: Show HN: I Wrote a Book on Data Analysis with Rust Notebooks

#10
post #8

I love Rust for systems dev, and I truly can't wait to read the article, because I can't imagine ever wanting to use it for exploratory data analysis, one-off stuff, or notebooks. Why deal with the borrow checker and compilation just to plot something in a notebook? Python is kind of ugly IMO, but it seems much quicker for prototyping.

In my opinion, we need a statically typed contender to R, Python and Julia. The use case is quite simple. Most data-oriented applications where you need linear algebra, probability theory, statistics do contain a significant amount of data pre-processing and business logic once extended to enter production. Here static typing is advantageous. Keeping the whole codebase in the same language is a significant advantage.…

> In my opinion, we need a statically typed contender to R, Python and Julia.

Nim is getting there.

Post reply on HN