The call for blogs was just issues a few days ago – and here I am writing about my biggest pains this year... because that's what the call for blogs basically is for me... I write down my pains with Rust and hope things get better slowly next year.

Don't misunderstand what I want to say here though: Rust is awesome, has an awesome community, awesome tooling, awesome everything... well not completely (because otherwise I wouldn't have to write this article, right?), but almost.

Pain #0: Libraries

Pain Number Zero (because that's where computer programmers start to count) is the library ecosystem. “What?” you say? “Rust is known for a really good library ecosystem although the language is not even five years old (counting from 1.0.0)“, you might say! And of course you're right... but not in my domain, unfortunately.

Rust has excellent libraries for developing web services backend as well as backend, gaming engines and games and of course microcontroller stuff. But these are not my domains. My domain is commandline user stuff. My domain might become TUI applications or even GUI applications in the future. My domain is data formats, especially icalendar and vcard, because I write journal applications, calendar applications, contact management stuff, todo applications and diary tooling and even Email processing/handling stuff and possibly even a CLI/TUI mail reader – of course I'm talking about imag here, the text-based, commandline personal information management suite I'm developing over four years now.

The tooling in this domain is not nonexistent, no way! But, despite the efforts some people in this awesome community started, the number and especially the quality of those libraries is nowhere as satisfying as the support for other domains. No offense to the libraries authors of course! It is not their fault at all. It is just that only a few people have started initiatives in this direction yet. I try to contribute! I am actually working on a libical high-level frontend which I started to extract from khaleesi, a work by two wonderful people which includes a wrapper around libical and libical-sys that I started to extract into a library crate.

But there could be so much more and better support for these things! I can only do so much. So I call out: Help developing libraries for these standards! Especially help developing high-level Rust libraries for these things, because handling mime as a way to work with emails is just the beginning. Parsing mail into something that can be worked with on a high level in Rust would be a wonderful goal for 2020. And of course all the other domains!

I remember from my days with Ruby that code could be written at a high level when working with mail and other such formats. Lets have that in Rust!

Lets have world-class support for handling data formats at a high level, so we can write “Speaking code” like it would be plaintext.

Pain #1 – CLI

My next pain are frontends. What I mean by that is CLI, TUI and GUI frontends, not WUI (web user interface) frontends. But I'll break this down into several sections here, so let's talk about CLI first...

One thing here is of course the wonderful clap crate. Lets make clap v3.0 happen next year! It would be a huge step forward!

But this is only one minor pain point, because clap is already a wonderful thing. Lets also make the interactive commandline user interface story better!

I remember that the people from the Node community have commandline applications that you can use interactively that just amaze me because they are so comfy to use (and I'm not even talking about TUI applications here, just interactive CLI apps)! I think we can have this in Rust!

Lets have the best libraries to implement interactive commandline applications!

Pain #2 – TUI

TUI is the next thing i want to point out. Short disclaimer though: I never wrote a TUI app, but I certainly plan to do so. Maybe not in 2020 but after that, imag should get a TUI interface at some point. And for that, of course, I would love to have a headache after thinking about which library or framework to chose.

Right now, there's cursive – and holy swearword this thing looks amazing! But there could be so much more, still! Of course there are already a few extension crates out there:

• cursivecalendarview
• cursivetableview
• cursivetreeview
• cursivebufferedbackend
• cursive-aligned-view
• cursive-async-view
• cursive-flexi-logger-view
• cursive-multiplex
• cursive-tabs
• cursive_hexview

(btw: @deinstapel you're a hero – they implemented half of the crates above!)

But I bet there could be more... I could think of an embedded terminal for cursive, I can think of an editor-view for embedding vim or another TUI editor into a cursive application, I could think of an editor-like view embedding the Xi editor...

Lets make Rust the go-to choice for writing TUI applications!

Pain #3 – GUI

And of course, the GUI domain. I could write up a long text here, or just point you to other Rust-2020 articles that expand on the topic... but I don't. Why? Because I never implemented a GUI application, I don't see myself implementing one in the near (or even far) future (at least not for imag) and so I don't take the liberty to reiterate what others said more eloquently: The Rust ecosystem for writing GUI applications is not good.

Lets improve our GUI-writing experience!

Summary

All in all, I hope that 2020 will be the year of the Rust Language as application language. We have an awesome tooling and frameworks available for web stuff, the game-domain is expanding constantly and low-level programming is possible and done out there all the time.

Writing applications in Rust is not yet as awesome as it could be, though. So my hopes, dreams and wishes are...

Lets make Rusts high-level application writing experience the best out there!

tags: #rust