The shift in Rust

This is my answer to the call for blogposts about what I’d like the year 2019 to mean for Rust.

But first:

What was accomplished

In my opinion, Rust was granted its wish. It got past its childhood, it is no longer an enthusiast language, used over the weekend. Well, it’s not only an enthusiast language and is not used only over the weekend. We see it being adopted by companies, sometimes visibly and proudly, sometimes more tentatively.

Great! Oh, wait… Rust, were you careful what you were wishing for? This is a whole new set of problems and challenges.

I’m from the enthusiast camp ‒ I use Rust over the weekend. But I also like it when I can use it during my paid work time and now I’m in the process of helping the company I work for to embrace Rust ‒ slowly, tentatively, but it’s getting there (I should have been careful what I was wishing for O:-). Let’s go over some things I see or suspect.

No more exciting language features

As an enthusiast, I always love to read the release notes mention something in the lines (this is an example, of course, and very exaggerated one!) „We are proud to announce Rust now comes with support for Monads. It’ll be a pleasure to rewrite everything using Monads, because they make the code so much clearer and more concise.“ I know the language is alive, and I know I have something new I can learn and try my skills on.

Now, let’s switch to the perspective of my colleague. He’s learning Rust. Hell, he came from knowing basic syntax to being fluent and proficient in it during a month of working on a Rust project, big respect to that. But he doesn’t learn it for the sake of learning, he learns it because it gets the thing done ‒ it runs fast, it eats little memory and it’s more comfortable and faster to write in Rust than in C++. He can’t spend the weekends learning new features of the language, because his two kids take all his weekends and evenings.

And here I’m talking about the first person that volunteered to try to do a project in Rust with me. In a year, there might be 10, with even smaller opportunity or will to learn new things. It’s possible to argue with management that the initial investment to learn Rust pays off. But there’s also the investment to keep up ‒ which should, generally, be small.

So, for this kind of person, new exciting big changes to the language are an annoyance.

I’m not arguing to freeze the language completely. There are little things one doesn’t have to really learn that much ‒ for example slice patterns. There’s not really anything to learn, we all have tried to use them even before they existed. It’s nice to add things like that. And there are also mostly invisible changes ‒ adding a new rarely used attribute, allowing procedural macros in some other contexts… But if you add HKTs or such, everyone will come to contact with them sooner or later, because someone else on the team will use it.

Forgive me for bringing C++ here. But I’m already dreading the C++20. They are bringing something like another 2 DSLs into the language (another two, in addition to all the ones that are already in there and the old ones are not going away). It makes me want to erase C++ from my CV, except that isn’t really that much of an option for me.

What I’m getting here at, the development of Rust as a language should become boring, in the same sense as it is said Rust is boring on the ops side. If you learned C 20 years ago, you can still say you know C, even if it had some new features.

With all that, the async-await notation clearly comes to mind. I surely must want that, right? And if you asked me half a year ago, I’d say yes, definitely. Now I’m starting to get more reluctant with the yes. I still think the benefits will overcome the churn it’ll cause (both in learning and around the ecosystem). But the cost of the churn is steadily growing as more code is being written and more people learn Rust. And I do think there could come a time when that reluctant yes might turn into a sad no.

Tooling

When transitioning from the public open-source development world to private world of a company, new needs that require different tools arise. The high standard of the open-source-aiming tools make their lack stand out.

For me and the company I work at, this boils down mostly to a private package registry, so we can share code between different projects but not publish it. A package registry proxy would be nice too (so our builds can keep running even if the Internet goes down).

I know cargo can work with private registries. But I haven’t seen a documentation how to set one up. I’m pretty sure this can be done, but something mostly drop-in would be great.

Libraries

Don’t get me wrong. Rust has some really great libraries. They usually have low bug ratio, superb documentation, feel natural to use around other libraries and do their thing well and fast.

But some libraries are either mostly missing, immature or feel alien (like, ports of APIs from other languages). All these non-essential things, like metrics and integrations with server management systems. I’m pretty sure companies working in slightly different environments will find some other areas not well covered.

And then there’s the next step. Even when I can find a library to get metrics where I want to (even if not using the protocol the ops team would prefer), I have to get the numbers somehow. Getting them from my own code is easy. Getting them out of another library is less easy.

I mean, for logging, most libraries already use the great log facade, but there’s nothing around metrics, around fault reporting that would be considered de-facto standard.

Furthermore, sometimes error reporting is also a bit lacking. Yes, libraries do provide errors (which is certainly a great thing, I’ve met libraries in other languages that just… didn’t report their errors at all, pretended that errors never happened and kept silent). But oftentimes, the error either contains the bottom cause (eg. „File not found“) or top-level result („Couldn’t load the document“). But it is missing some kind of context I’d definitely like to know to fix the error if I read it in the logs (like, what file, or why wouldn’t a document load).

I guess most of this comes from years of usage and enough users to keep reporting and sending merge requests. So in a sense, this’ll resolve itself over time. On the other hand, maybe having some accepted best practices how to do these things effectively would help.

Putting an application together takes more work than I’d like it to. I really do enjoy crates like structopt that lets me declare command line arguments as a struct with derive attributes. But this is only a piece of the whole puzzle and I still have to connect all the pieces. I’m trying to do something on that front, but I’m not sure I’m very successful there.

Conclusion

I hope I don’t sound negative. Rust is expanding to places where it wasn’t previously and that brings new problems, but that’s to be expected. In fact, I’m mostly positive, I just want to share the places where I feel most work is needed.

Anyway, my feeling (or wish) is that the focus should move somewhat away from the language and more towards some kind of coordinated effort towards libraries, polishing, documentation, etc. I know, it is less exciting ‒ spending time fixing error messages or writing documentation is definitely less fun than trying to come up with a way to pin data structures to memory and while both are very useful, I think Rust will now benefit more from the first than the latter.

And, finally, thanks everyone for the great work. Even with all these problems with young libraries and lack of certain things, Rust feels like the best tool for many a problem, and enjoyable to use on top of that.