I hope you're using any sort of logging in your applications. Even if that
means printing stuff to stdout and relying on shell output redirection,
it's still better than no logging at all. However, most programming languages
have great libraries for logging. Be it Java, Python, Elixir - there are
logging utilities everywhere. But more often than not, what is logged is some
sort of prose that a programmer thought was applicable at a time.
I once wrote this line of Python code:
logger.error('Oh no, something terrible happened: %s',details)
Even though I've configured my logging levels, formatters and other stuff
that's very useful, in the end I still had to grep terrible to find
what actually happened, and later parse the details with a nasty regexp.
Not very convenient. Structured logging is a concept that puts events
over messages; we're now logging events with associated key-value data,
not plain string messages.
Let me start this article with a confession: I suck at writing parallel code.
I have only a vague idea about mutexes, locks and other low level primitives
for handling data between threads. And since I work mostly with Python,
I tend to use multiprocessing (if I bother to parallelize at all) rather
than threads.
However, one of the selling points of Rust is its approach to
concurrent/parallel programming. Mozilla recently
released a video
encouraging people to write parallel code that is safe and approachable.
Then I heard about rayon - a library for
data parallelism that is very approachable and lightweight.
My engineering diploma involved some digital signal processing (DSP),
in particular sound generation and recognition. Throughout my studies
I went through a ton of audio files, usually using C++ to process them.
I've written a custom .wav file loader, of course missed a few edge
cases and it crashed upon receiving new training data from my supervisor...
A few months later I discovered that Python
suports WAV in the standard
library. Since then I try not to reinvent the wheel when it comes to processing
.wav files. Luckily there's a great library for doing that in Rust -
hound.
Two years ago in December 2014 the
first edition was pretty well
received by the Rust community. That was a hard time - we were still before
the 1.0 release of the language. I had to keep up with updating my examples
day by day since almost every nightly broke something. Even so, I managed
to publish all 24 blogposts on schedule :-)
This year I'm back with another series of articles about Rust tools and
libraries. The languge is at version 1.13 as I'm writing this introduction.
It's definitely more stable and mature at this point than it was in
those savage pre-1.0 times. Some of my examples will probably still require a
nightly release, but I'll try to keep them updated when relevant features get
into stable.
With that, let's dive in into our first topic, which is....
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.
So, 24 days have passed since the first article in the series. This means, sadly, 24 days of Rust is coming to an end. I hope you learned something from my articles or at least found something interesting about Rust to dive in. For me it was a great experience too, I learned a ton while doing this. Sometimes it was stressful too - breaking changes coming to rustc on a daily basis meant a considerable amount of work! A few times I had an already drafted article on some subject, only to discover the code blows up with the newest nightly and I have to change the topic. So here I go looking for something that works on that day, or fixing dependencies of dependencies just to make the examples compile. But no more complaining - there's something very positive I wanted to say today.