Rust is a wave of the future

May 24, 2021

Recently I tweeted:

Once again I am being tempted to try out Rust, despite a relatively high confidence that I'm going to not like it. It's the wave of the future, though. Sooner or later I'm going to have to read and hack on Rust code.

More than five years ago, I wrote an entry on my feelings on using on Rust myself which I have since summarized to people as 'Rust cares about things that I don't any more'. I understand that Rust has much better ergonomics than it did in 2015 (when Rust 1.0 was just out), and so some of my other issues might be better.

But that's not why Rust is a wave of the future (in the manner of tweets, I said 'the wave'). Rust is a wave of the future because a lot of people are fond of it and they are writing more and more things in Rust, and some of these things are things that matter to plenty of people. There's Rust in your Python cryptography. There's Rust in Curl (sort of) (also). There's Rust in your librsvg. There's a lot of Rust in your Firefox. There are a growing number of command line tools written in Rust, including the excellent ripgrep. Someday there will probably be Rust in the Linux kernel. All of this is only growing with time, especially in the open source world.

All of this means that dealing with Rust is going to become increasingly necessary for me and a lot of people. We may not write it, but we need to be able to deal with programs that use it and are written in it. Our systems increasingly need a Rust build environment, I recently explored Rustup, and sooner or later I'm going to have to read and perhaps change Rust code in order to understand some problem we're having and perhaps fix it. Learning how to write some Rust myself is one way of getting the experience and knowledge necessary to do that well.

By the way, this isn't some nefarious conspiracy to force Rust on everyone. Some of it is that Rust really does solve problems that people have, but as I mentioned, a larger part of it is that lots of people genuinely like writing in Rust. When people like a programming language, things get written in that language and some of them become widely used or popular (or both). We saw this with Go in certain areas, and we're seeing this with Rust.

(There's an interesting question, one that I don't know the answer to, about why we haven't seen this for various other languages. Of course we have seen this for some; Javascript is large now and there are general tools written in it, and Java was large once upon a time. Some of it is likely that Rust can be airlifted into C and C++ programs relatively easily, but that doesn't explain programs written from scratch.)


Comments on this page:

Yes, I know the feeling. I wrote a rust-entry four years ago on why I didn't like rust: https://medium.com/@ineiti/rust-rant-e24ad62f76e8

TLDR: I didn't like being able to crash the compiler after two hours into a new language ;)

But I started again at the beginning of this year. It still has a lot of rough edges, and a lot of libraries are still missing, others are three times multiplied (std::async, futures, tokio, for example). But for the first time there are some things that I cannot find elsewhere, like a good, small, wasm support. Or a tor-library like arti.

So I'm programming in Rust now, at least a little. It's not that bad anymore. But a lot of the things you write about, borrow, mutable, ... still feel like it should be the compiler's work, and not mine. I hope this will come.

Ineiti

By nyanpasu64 at 2021-05-25 16:30:12:

Reminds me of https://www.gwern.net/Holy-wars. For example, now that (librsvg, cryptography, Firefox) uses Rust, you can't build recent up-to-date versions of them for a CPU architecture that Rust doesn't support.

By jrp at 2021-05-26 10:37:12:

A few random thoughts, if you will permit me:

If you're going to give it a shot again, may I commend to you using a modern dev environment? I couldn't envision going back to something like emacs and the language bindings: I happen to be pro-jetbrains, so I use clion b/c I do some windows things, others have used intellij to great effect (I couldn't get the unstable to run), and the windows visual source thing does not seem to be terrible either.

You will 100% still run into various compile-time difficulties, but it's been my experience that, while compile-time frustration starts high and occasionally gets bad, actual bugs in my code decreased. I feel more confident now, although I still code agile-defensively (that is, write as little code as possible with as great flexibility as possible).

For me, the #1 benefit of rust is the extensive, centralized, usable, accretable crates that can be leveraged, and the relative safety and streamlined experience around using OSS. Good IDEs help one leverage that, because writing rust is as much - or more - a process of integrating other libraries as writing one's one critical code. There are lacunae in the OSS support for various things, I'll grant, especially compared with, say, python. It will come with time.

I can envision rust being the thing to deal with web and cloud back-end processing, glue (despite the lack of abi), system and OS stuff with the sort of longevity of decent C.

We've changed the way we write software, most everybody has to leverage massive externally maintained subsystems in the way we used to rely on STL or third party paid libs. I feel a bit safer using an arbitrary rust crate than I do using an arbitrary python package.

"Easy to use" means, partly, BSD or MIT licensing, and the rewards are bearing fruit: making it easier and easier for professionals to be able to (without being forced to do things, which stops people participating) 'give back' will help float the software economy by putting forth the best items. Also, the concepts of 'nightly' and 'stablized' can be fruitfully used in professional development environments as well (specifically, when there are clear benefits, arguments like "this is how we do things now" are actually pretty effective.)

Finally, while we all have our necessities, consider writing and maintaining one crate for the long-haul.

jrp

Written on 24 May 2021.
« Why we don't have management connections to our switches (an old story)
Working around an AMDGPU automatic fan control problem on my Radeon RX 550 »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon May 24 23:43:02 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.