Category Archives: Programming

Sqlite3 – How Slow Is Write?

Sqlite3 is lightweight relational database, mainly focused on smaller local systems. Being used in Android it’s now probably most spread relational database in world with billions of instances running. Lite in the name means that it is not client-server architecture and it’s intended for lower data volumes – ideal usage profile is read mostly, with occasional writes. Sqlite3 is often used as an embedded data store in various applications (Firefox and Chrome are most prominent ones). Recently I’ve been playing a bit with sqlite3 interface in Rust and had run couple of simple tests especially focused on writes. So how does sqlite3 performs and how it compares with other more typical client-server RDBMS like PostgreSQL?  It’s not any serious benchmark, just couple of toy tests to highlight few things. Continue reading Sqlite3 – How Slow Is Write?

Future Never Sleeps

Recently I’ve been reading this book:  “Network Programming with Rust” by Abhishek Chanda. I found this book bit problematic. It’s just collection of many unrelated examples (often taken from crates documentation), with just little of background and concepts explanation and in some parts this book is just wrong, in other parts it’s using too much simplifications, so the result does not make much sense or worst it introduces some dangerous ideas. One of these  places is part about futures and streams – let’s look at one example: Continue reading Future Never Sleeps

Fearless Upgrades with Typed Languages

One of many advantages of statically typed programing languages like Rust or Java is their resilience to changes in dependent libraries, usually caused by new library versions with modified interface – e.g. the major version changes. In statically typed language we usually see problems in compile time and it should be relatively easy to fix, but in dynamic languages such as Python or Javascript upgrade is more challenging and problems  demonstrate themselves during tests (in better case, when we have good test coverage) or in production in worst case. I had recently came through this process for couple of  relatively small projects in Rust. Couple of dependencies (hyper and tokio) had been upgraded to new versions with significant changes to their interface. With update compilation broke with tens of errors, but gradually I was able to fix all of them (in one case it required to improve error handling with custom error type, plus using additional new library, as typed headers were removed form hyper) and after code compiled and run through basic tests I was pretty sure that I’m fine with new libraries. In similar situation in python I would need much more work to be sure that code works after such major upgrade of dependencies. In practice it enables easier maintenance of code and less effort  to keep it up to date with latest libraries. For library authors it provides more freedom and they can introduce breaking changes more often (with great cargo build tool in Rust library users can pin themselves to older version, if they do not want to upgrade).

From Ignorance to Enlightenment – Playing with Tokio

I have been playing with tokio already in couple of small projects (ptunnel-rust and indirectly (via hyper) in audioserve), but I cannot say that I’m proficient.  Also tokio is very much moving target –  what I used couple month ago is already bit outdated now(old version is tokio_core crate – where default executor was on current thread, now it’s work stealing thread pool). So I decided to refresh and deepen my knowledge and created a toy project –  stupid jokes server –  it’s a TCP sever, which sends a random  joke to client after it connects and then closes connection. Jokes are stored in text file, separated by dashed lines.  My main interest was to test how to use local file system I/Os, which are blocking by nature, with tokio asynchronous approach (so I initially skipped easiest and probably most efficient implementation, where all jokes would be cached in memory).  Usually in a real project you’ll have some blocking code, so I need to know how to handle it. This article is history of my attempts (and failures) recorded in a hope that it might help others in learning tokio (and also writing it down helped me to absorb gained knowledge). Continue reading From Ignorance to Enlightenment – Playing with Tokio

How much better is the thread pool?

Is thread pool worth to consider for my project?   I was  looking for some opinions around the net and as usual they  differ and most common wisdom is it matters. Generally it’s “known” that creating and tearing down thread is “significant” overhead, so if you have a lot of small tasks thread pool is much better solution then spawning new thread for each task.  But what is significant overhead?  According to what I read time to create thread on Linux should be about 10μs (which does not look as too much to me) and app. 2MB of memory allocated for stack (configurable).   I was considering thread pool in context of audioserve project, where I started with simplest possible solution (e.g. spawning individual threads ) and was wondering how much I’m loosing by not using thread pool. So I implemented simple thread pool (as learning exercise – long term audioserve solution should use tokio-threadpool)  and add it to audioserve.  In the remainder of this short article I’d like to share my findings and  roughly quantify benefits of thread pool for such small project. Continue reading How much better is the thread pool?

From Russia with Love – Kotlin Language

One may think that we have already more then enough programming languages. But community thinks differently and new languages keeps popping up and thanks for that, because some  bring cool innovative features, others focus on more streamlined and effective development, but all of them contribute to the evolution of the IT industry. Because as in the nature progress comes through the variety of species and competition between them.  As I have written in my past article I looked recently into Rust language – very interesting language, which comes with novel approach to memory management without garbage collection, but still assuring high security of the program.  Nowadays I met another member of ever-growing happy family of programing languages – Kotlin and I’d like to share my first experiences in this article. Continue reading From Russia with Love – Kotlin Language

Audioserve Audiobooks Server – Stupidly Simple or Simply Stupid?

If you read some of my previous articles you know that I’m quite fond of audiobooks.   In past I was looking for good media server, which supports audiobooks  and ended with  airsonic (a subsonic clone).   The problem with majority of media servers is that they rely totally on audio tags, which are often messed in audiobooks. Also many of “advanced” functionalities are not applicable to audiobooks (random play, shuffle tracks, moods, etc.)  I’m bit of old school so I rely more on reasonable directory structure and do not want to mess with tags for every audiobook I download. I also think that for personal collection I do not need likes, favorites, sharing and similar stuff,  as I can easily remember which books are good and which I have listened or want to listen, but I do need few things, which are usually missing – like bookmarks. Interesting function is to continue listen on a device, when I left  on previous device, but since I basically listen only on my mobile phone, it does not seems to be critical. So ideal audiobooks server actually requires much less functionality than today’s media servers provide.  As I’m progressing with Rust language I decided two weeks ago to create simple audio streaming server adhering to KISS principle – Keep It Simple, Stupid, – Result of this exercise is an  application that provides minimum viable functionalities for streaming and listening of audiobooks – it’s called Audioserve.  In this article I’ll show it’s basic design and demo current application in a video. Continue reading Audioserve Audiobooks Server – Stupidly Simple or Simply Stupid?

The Different Approach to A Parser – Parser Combinators

Some time ago I’ve looked into building parser for simple logical language used by imap_detach Tool. I used there parsimonious module which uses PEG grammars. Recently I learned about another parsing technique – Parser Combinators. The idea comes from functional programming and is about combining (with help of higher order functions – so called combinators) simple parsing functions, which parse primitive tokens, into more complex parsing functions, which parse parts of text and further combine those into more complex ones, ending finally with one function, which parses all given data. I first met with parser combinators in Rust library nom. Here parsers and  combinators are express as macros, which is convenient on one side (concise syntax), but can lead to pretty cryptic error messages and one cannot rely much on editor’s help with auto-completions, context help etc..  I used nom to build very simple URI parser.  I was wondering also if parser combinators are available for Python and how they would compare with other approaches – like above mentioned PEG grammars. Continue reading The Different Approach to A Parser – Parser Combinators