Thoughts on Rust in 2019
2018 was a success with the stated goals of releasing “editions” and working on usability/ergonomics. My first encounter with Rust was pre-1.0 (early 2015) and I immediately saw that Rust would be my future, wherein I joked to colleagues that I’d use it to “make toasters talk”. Followed by a sizeable hiatus (lack of personal time), I came back mid-year 2018. I can say for certain that the focus on usability and ergonomics was successful. Rust is much easier to use now than it was then. Rust format (rustfmt), Rust language server (RLS), text editor support, cargo tooling, compiler messages, and ecosystem crates’ quality and diversity are all amazing. The community is crazy diverse (first language learners, experienced systems people, web-dev people, programming language theory people, etc…). The chaos is well-managed with self-organizing working groups.
On a personal note, time is sparse between homework/coursework for my math degree, the day-job, and building my own company (the normal way, no VC-backed mafia). I don’t often get to contribute to open-source projects but the time I have will be focused on what I’d like to see in Rust 2019. And, for the record, I’d still like to make my toaster talk to me.
What I’d like to see in 2019
- Stable low-level mathematical packages (nalgebra, ndarray, statistics, probability, calculus)
- (Web)Serving (Python/Julia built) deep learning models
- Data processing infrastructure
- Easier to use concurrency primitives and networking
My list comes from an underlying desire to see Rust carve out significant space in computational mathematics. What I mean by computational mathematics: Artificial Intelligence, Machine Learning, Natural Language Processing, Computer Vision, Numerical Optimization. The current state of affairs (and state of the art) is founded largely in C++ with Python APIs; Julia is also making stunning progress and don’t forget about Haskell and Scala. Having stable, low-resource, and easy to maintain mathematical libraries that can be used by Rust projects or from Python, R, Julia, Go, Ruby, Nodejs is a reality I’d like to work on. Rust may not cut it as a research language in mathematics (it’s not interactive nor does it have the complex type systems that Haskell or Scala have) but it certainly is a strong contender for building long-term support math libraries for well known problems (the kinds of software that can productively live for 50+ years).
There is a good reason to want garbage collected dynamic typed higher level languages (or language APIs) in fields where research, discovery, experimentation, and ad-hoc analysis take up a majority of development time. Python, R, and Julia dominate here and there’s no reason to buck this trend; it works well. There is also no reason why Rust cannot, and should not, begin to provide high quality mathematics libraries for use, specifically from Python; maybe even Julia.
Julia is paving the way for high-performance dynamic typed languages. And if I need a machine learning task I’ll look to Julia first. The focus of Julia is on scientific software… this means non-CS academics, researchers, and scientists. Rust is not targeting academics and scientists, nor should it. Python and R have been and will continue to be the big players in this space. Python/R/Julia allow rapid prototyping and provide high quality scientific computing environments to people whose profession is not software first. But these benefits come with a cost.
The typical downsides of dynamic typed languages for maintaining large code bases across teams of developers where stylistic preferences, hidden performance gotchas, unknown or unknowable run-time bugs, and risk in big refactors will always be a concern here. Researchers will probably always need a different set of tools and programming languages than software engineers will. It is unlikely that science-and-math-based mission-critical or profit-critical services will be deployed with the same software used to R&D the main insights that led to the service.
When research ideas stabilize and it’s time to go to production I would like more alternatives for static typed, non-garbage-collected programs. Specifically for solutions where one might be serving a deep learning model behind a web server (or serving such a model on a toaster). Julia is amazing and Python has all the mind-share… but if I’m looking to put something behind a web-server I’ll be looking at Go… and Rust 2019!
Easy to use, stable, and production worthy networking solutions are a must for Rust. Everyone knows it and it’s well advertised. I would like to see better infrastructure and workflows in taking machine learning models from Julia/Python R&D to low-latency and low-resource web-servers in Rust!
Research and development for non-CS people is probably not a strength for Rust. But stable, long term support and production ready libraries, platforms, or services certainly can be. Building a machine learning model is one thing, serving it in production is entirely another. Additionally, one must fetch and manage the data too; and this may be the area Rust can best contribute to the future of information services.
Data processing infrastructure is a place where Rust can really shine (think Hadoop, Spark, Kafka). Rust may not have the advanced type system capabilities of Scala or Haskell but it is sufficiently complex to compete, particularly within low-resource constraints. Currently for any low-resource tasks and/or networking services I’d reach for Go. I’ve written my share of web servers and data processing infrastructure in Go, and it is phenomenal. But there are places where I’d benefit from a more complex type system (ahem, generics!) and/or no GC.
One of the core competencies of data infrastructure is both concurrency and parallelism. I’d like to see Rust concurrency primitives that are as easy to use as Go; I doubt I’m alone here. Easy to use networking and concurrency (and parallelism) would make Rust a very attractive environment for building the next generation of high-volume low-latency data services.
What currently exists?
Here are some projects that I am particularly excited about (none of which I am affiliated with).
Snips NLU (Natural Language Understanding)
Snips is a company building voice systems for embedded devices. They have a number of really great Rust projects.
Snips NLU rust implementation. Contribute to snipsco/snips-nlu-rs development by creating an account on GitHub.github.com
TVM is a pretty cool project from the DMLC (they work on many other cool projects, including XGBoost).
Rust bindings for TVM runtime. Contribute to ehsanmok/tvm-rust development by creating an account on GitHub.github.com
PyTorch to C++ (-> Rust?)
Compile a PyTorch deep learning model to C++, create a C API, wrap with Rust. Seems like a lot of work, maybe…?
As its name suggests, the primary interface to PyTorch is the Python programming language. While Python is a suitable…pytorch.org
An amazing library, used by the author to build a recommendation system; also built a Go wrapper.
Autodifferentiation package in Rust. Contribute to maciejkula/wyrm development by creating an account on GitHub.github.com
Fantastic and ambitious project for which not enough financial nor community support has materialized.