Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

A few days ago the Rust subreddit got excited about the rebirth of rusti - an interactive shell for Rust. Such interpreters (sometimes called REPLs - read-eval-print loop) are the bread and butter of dynamic languages like Lisp, Python or Ruby. But that is not a requirement - as Haskell demonstrates with its GHCi, you can have a REPL for a statically typed, compiled language too. rusti is an attempt to build such an interpreter for Rust.

Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

Today I'm revisiting the topic of database access in Rust. I mentioned PostgreSQL client library a week ago. This time we'll move from SQL to NoSQL land. Our focus for today will be Redis - a data structure server. The redis crate is a client library to access Redis from Rust.

Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

In Rust there is no concept of a constructor as a language feature, like for example in C++. However there is a strong convention (and mentioned in the guidelines) to use a static method called new as the constructor. This works well, but you can have only one function called new in the impl - there is no method overloading. So are we out of luck if we want to have different constructors? No! But arguably different purposes should imply different method names, so another convention is to prefix extra constructors with with_ (such as Vec::with_capacity) or from_, if the constructor does some kind of a conversion.

Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

We finished part 1 with a working FUSE filesystem representing an empty directory. Today we will continue the story and finally add some files to the mix.

Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

A traditional filesystem is typically implemented as a kernel module. However, some Unix-like operating systems (Linux, FreeBSD, Mac OS X and a few others) allow for userspace filesystems through a mechanism called FUSE. The canonical FUSE library is written in C and there are some bindings from other languages (Python, Ruby etc.)

The fuse crate is very interesting because it's a rewrite from C to Rust, leveraging many of Rust features unavailable in C. The only binding to libfuse is related to mounting and unmounting the filesystem, the rest is pure Rust.