Rust severely disappoints me

I wanted to like Rust. I really did. I’ve been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec.

I finally cleared my queue enough that I could spend a week learning Rust. I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.

My chosen learning project in Rust was to write a simple IRC server. As a service daemon with no real-time requirements written around a state machine of the kind I can code practically in my sleep, I thought this would make a good warmup for NTP.

In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server.

Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.

The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste.

Then I found out that a feature absolutely critical for writing network servers is plain missing from Rust. Contemplate this bug report: Is there some API like “select/poll/epoll_wait”? and get a load of this answer:

We do not currently have an epoll/select abstraction. The current answer is “spawn a task per socket”.

Upon further investigation I found that there are no proposals to actually fix this problem in the core language. The comments acknowledge that there are a welter of half-solutions in third-party crates but describe no consensus about which to adopt.

Not only that, but it seems the CSP implementation in Rust – the most tractable concurrency primitive – has limits that make it unusable for NTPsec’s purposes (only selection over a static set of channels is possible) and there is some danger that it might be removed entirely!

I have discovered that Rust is not, or not yet, a language suitable for long-term infrastructure work. It suffers from a damning combination of high barriers to entry and technical deficiency. What is worse is that Rust’s community seems to be unable to fix or even clearly grasp these problems.

I think one problem here is the absence of a strong BDFL providing tasteful design direction and setting priorities. The Rust community appears to have elected to use the decentralized nature of their crate system (which undeniably has some very nice technical properties) to execute a swarm attack on the design space around the language. Which is wonderful in theory but seems to be failing in practice.

UPDATE: This post attracted two kinds of pro-Rust response. One was stupid flamage from zealots. The other was thoughtful commentary from a few people close to the core of the Rust community. The latter group has convinced me that there is considerable awareness of the problems I ran into; a couple even agreed, after analysis, that Rust is at present a poor fit for NTPsec’s requirements. This gives me hope that the Rust of five years from now may become the mature and effective replacement for C that it is not yet.