Vorner's random stuff

Rust 2018

There’s a call for the community to write what they’d like to see in Rust in the following year. So, here it goes. And yes, this is a bit personal, what I would like to see in Rust ‒ I fully respect that others have different needs and that not my every wish need to be granted, because someone else will have a better idea for sure.

However, I always need to have something special, so I decided I don’t want to just plain list what I’d like to see, but what I wouldn’t like (and also something about what I already like).

The already good stuff

Compile times. It might sound strange, but I really don’t complain about the speed of Rust compilation. I work with C++. I’ve tried Scala. Rust’s compile times are perfectly OK. With incremental compilation, small changes usually get processed faster than an average C++ build system decides what not to compile. But sure, if it works even faster, that’s great, I won’t refuse.

Another thing I find good enough is documentation. Well, more than good enough. Try using a library like NFQUEUE. You mostly start hunting the Internet for a piece of code that uses it and hope it does so correctly. If you want to do something slightly different, you go experimenting and hope the fact it doesn’t crash means you do it correctly. Or maybe even Google’s gRPC. What would you guess a method BuildAndStartServer does? Yes, of course it builds a server. To start it, you call Wait on it. Isn’t that clear? If not, the documentation won’t help you a single bit.

I guess all this may be OK for me, because I come from the rough world of C and C++, not from Ruby or Python. I can see the compile times are still a bit worse than what Python offers, most of the time.

And one really great thing. Rust, or the community around it, fully recognizes it is not just about the syntax of the language, that it is much broader ‒ from the library ecosystem through tools to actual people. I haven’t seen such concern elsewhere. Usually, a company or other entity just produces a language and calls it done for the day. Or its committee solves a lot of non-existent problems (in addition to some of the existing ones), takes ages to do so and ignores some basic use cases like showing an error message why reading a file failed.

The things to improve on

There are things that I find a bit annoying and would like if they improved (I find such things on everything in life).

First, something of a quality assurance about crates. When I pick a library to perform a goal, it may be a great masterpiece (and there are such available) or low-quality broken attempt which crashes and is left to rot by the author (these are available too, possibly even by me). I might want to know if the crate is not sound. I’d like something more that how nice the name and readme looks to guess upfront, before using it or trying to read its code. Number of downloads isn’t necessary a valid gauge if the library is for a minor use case.

Second, one practical thing. RLS is a really nice tool in terms of features and I love it. When it works. Which isn’t always. If I open a project, it crashes in like 50% of times. It would need some work on its reliability and stability (or maybe some automated test suite, to pick a crate at random, try to issue some analytical commands on its code, etc).

The third one for me is something I call „eternal RFCs“. Sometimes, an issue is identified, someone writes an RFC, it is discussed and implemented. And then it sits there for ever, waiting for stabilization. Sure, some are hard to get right ‒ macros 2.0, generators ‒ and I see why these take so long (it doesn’t stop me from wishing they were stabilized last month already). But there are so many tiny ones that just seem forgotten ‒ to pick some, AtomicU8, --print target-spec-json. I believe it should be possible to set some expiration date on each RFC and then have it remind itself (by a bot), and make a decision to

And fourth, it would be great if companies started to use Rust more (to have more Rust jobs, make it economically worthwhile learning it, so we can enjoy our day jobs more). I think it is inertia in large part (in addition to solvable problems like private crate registries). If company is using C++, moving to Rust means teaching everybody a new language, which takes resources and it isn’t the right time now (hint: it never is), even if it brings benefits in the long term. And, switching languages is perceived as risky. For the risk, more success stories could help (like the one with Firefox’s CSS engine). An incomplete idea, but would it make sense to ask the companies in the „Friends of rust“, if they could each provide one and collect them? Something to show the other companies why they want to invest in Rust ‒ something more than 2 sentences or story „We did this great thing… and by the way, we used Rust on the way“. Something to highlight why it was Rust, how it helped, but also where the pain was.

Things not to do

I think Rust should not abandon its goal at being true „systems language“. I use the term in quotes, because it is so overused these times and nobody really knows what it means.

There’s a lot of new languages these days. Many of them are „just“ Yet Another Compiled Python. Basically, someone decides to save the world by making the best language ever. A language that solves all the problem for the programmer. They end up with a variant of something with garbage collector, reasonably good performance because it is compiled, pleasurable syntax, package manager and one little feature that sets it apart a bit from the rest. And then decide to call it „systems language“, because it is good for marketing and everyone wants system languages these days. And call it safe, because there are no dreaded pointers directly available. Not that this would be wrong. These are OK languages. They are easy to use. They get the job done. They just don’t bring much new to the game and there’s plenty already.

However, I see Rust as unique in a way it doesn’t mask the user from the complexities of a problem. It fully admits that but it arms the user with tools to make the complexity manageable. The admitting of the complexity puts Rust in a group of languages of the last resort (but the tools are unique in the group).

What I mean, when you’re choosing a language, you may do it based on how many programmers around you know it, how much you like it, how easy it is to use, if it has the right libraries, or if you just like its logo. Most of the time, you have literally hundreds of possibilities. But sometimes, the problem chooses for you and you have to pick from C or C++. Or now Rust. And that’s it.

I believe it is important for Rust to stay in that group of languages and not become Yet Another Compiled Python, we have plenty of those. We just have very few of the last resort ones. And I mean it even if it means Rust isn’t as pleasurable or easy to use (the others in the group aren’t either). I don’t mean to say Rust should aim to be hard to use. It’s great Rust tries not to compromise and wants to just do both at the same time. But I still consider the possibilities of use for all types of problems more important. If someone can afford to use Go or Swift and doesn’t want to use Rust because it is more complex (or because a gopher is obviously much cuter than a cogwheel), good for them ‒ there’s a place for more than one language in the world.