Rust: A Critical Retrospective

[nu11ptr]

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read

I'm a huge Rust fan, but sort of agree. First, I dislike C-style syntax in general and find it all very noisy with lots of unnecessary symbols. Second, while I love traits, when you have a trait heavy type all those impl blocks start adding up giving you lots of boilerplate and often not much substance (esp. with all the where clauses on each block). Add in generics and it is often hard to see what is trying to be achieved.

That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up. I've even done some prototyping of what alternative syntaxes might look like and they aren't much improvement. There is just a lot of data that is needed by the compiler.

In summary, Rust syntax is noisy and excessive, but I'm not convinced much could have been done about it.

[api]

IMHO it's at least somewhat better than "modern" C++ where you end up having to wrap virtually every single thing in some kind of template class, and that's without the benefit of much stronger memory and thread safety.

Overall I think Rust is a hands-down win over C and C++. People who want it to be like Go are probably not doing systems-level programming, which is what Rust is for, and I have severe doubts about whether a rich systems-level language could be made much simpler than Rust and still deliver what Rust delivers. If you want full control, manual memory management with safety, other safety guarantees, a rich type system, high performance, and the ability to target small embedded use cases, there is a certain floor of essential complexity that is just there and can't really be worked around. Your type system is going to be chonky because that's the only way to get the compiler to do a bunch of stuff at compile time that would otherwise have to be done at runtime with a fat runtime VM like Go, Java, C#.NET, etc. have.

Go requires a fat runtime and has a lot of limitations that really hurt when writing certain kinds of things like high performance codecs, etc. It's outstanding for CRUD, web apps, and normal apps, and I really wish it had a great GUI story since Go would be a fantastic language to write normal level desktop and mobile UI apps.

[jillesvangurp]

Something like Kotlin but with a borrow checker might be the ultimate in developer ergonomics for me. I sat down at some point to wrap my head around Rust and ended up abandoning that project due to a lack of time. And because it was hard. The syntax is a hurdle. Still, I would like to pick that up at some point but things don't look good in terms of me finding the time.

However, Rust's borrow checker is a very neat idea and one that is worthy of copying for new languages; or even some existing ones. Are there any other languages that have this at this point?

I think the issue with Rust is simply that it emerged out of the C/C++ world and they started by staying close to its syntax and concepts (pointers and references) and it kind of went down hill from there. Adding macros to the mix allowed developers to fix a lot of issues; but at the price of having code that is not very obvious about its semantics to a reader. It works and it's probably pretty in the eyes of some. But too me it looks like Perl and C had a baby. Depending on your background, that might be the best thing ever of course.

[shadowofneptune]

The same information can be communicated in different ways, trading one form of noise for another. I have a personal preference for Pascal-like or PL/I syntax. Instead of int *char x or int&& x, there's x: byte ptr ptr. It's more to type and read, sure, but sometimes having an english-like keyword really helps clarify what's going on.

[ducktective]

> I found Rust syntax to be dense, heavy, and difficult to read

Reminds me of this section of Rich Hickey talk: https://www.youtube.com/watch?v=aSEQfqNYNAc

[dhosek]

Familiarity also alleviates the issue. I can remember when I first encountered TeX in the 80s and Perl in the 90s and thought the code looked like line noise and now I no longer see that (even in Larry Wall–style use-all-the-abbreviations Perl).

[hawski]

I find that Rust tends to have code that goes sideways more than downward. I prefer the latter and most C code bases, that I find elegant are like that.

It is like that, because of all the chaining that one can do. It is also just a feeling.

[dingoegret12]

I love Rust and use it everyday but the syntax bloat is something I will never get over. I don't believe there's nothing that could be done about it. There are all sorts of creative grammar paths one could take in designing a language. An infinite amount, in fact. I would really like to see transpiler that could introduce term rewriting techniques that can make some of that syntax go away.

[sph]

There's definitely a space for native languages that are not as dense and performant possibly as Rust. I will trade some readability when I need strict memory guarantees and use Rust, but most of my time I'd like to use something readable and fun to use, which Rust ain't.

I used to use Go, not much of a fan anymore, but I'm liking Crystal a lot to fill this space. Eventually Zig when it's more mature.

[runevault]

Your summary is the thing I struggle with as well. How do you deal with the issues of density without either making it more verbose by a wide margin (which also hampers readability) or hiding information in a way that makes the code less obvious which is, IMO, worse.

Software is becoming more and more complex and unless there are entirely different design patterns we have failed to find, managing and understanding that during both the writing and the maintenance of software is the fundamental problem of our time. Someone else in these comments mentioned leaning more heavily into IDE tooling and I do wonder if we are coming to a point where that makes sense.

[codebje]

> That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, …

I am not convinced that there's so more to Rust than there is to GHC Haskell to justify so much dense syntax.

There's many syntax choices made in Rust based, I assume, on its aim to appeal to C/C++ developers that add a lot of syntactic noise - parentheses and angle brackets for function and type application, double colons for namespace separation, curly braces for block delineation, etc. There are more syntax choices made to avoid being too strange, like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc).

Rewriting the example with more haskell-like syntax:

    Trying::to_read::<&'a heavy>(syntax, |like| { this. can_be( maddening ) }).map(|_| ())?;

    Trying.to_read @('a heavy) syntax (\like -> can_be this maddening) >> pure ()

It's a tortuous example in either language, but it still serves to show how Rust has made explicit choices that lead to denser syntax.

Making a more Haskell-like syntax perhaps would have hampered adoption of Rust by the C/C++ crowd, though, so maybe not much could have been done about it without costing Rust a lot of adoption by people used to throwing symbols throughout their code.

(And I find it a funny place to be saying _Haskell_ is less dense than another language given how Haskell rapidly turns into operator soup, particularly when using optics).

[codegeek]

I wanted to learn Go while working professionally with PHP and Python. I loved the simplicity and syntax of Go overall. I learned Go enough to build a small internal tool for our team and it is Production ready (at least internally). Then I wanted to learn Rust since it is so popular and always compared with Go and the syntax made me lose interest. Rust may be amazing and I will be more open minded to try later but it didn't spark the interest. Superficial I know since the real power is in functionality etc but just an anecdote from an amateur.

[queuebert]

Completely agree. I think of the extra syntax as us helping the compiler check our code. I have to write a few more characters here and there, but I spend way less time debugging.

Although I may have PTSD from Rust, because lately I find myself preferring Qbasic in my spare time. ¯\_(ツ)_/¯

[amelius]

> Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python

True, but Rust is being used for a lot more than just system programming, judging from all the "{ARBITRARY_PROGRAM} written in Rust" posts here on HN.

[logicchains]

>That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up.

Have you checked out C++20 concepts? It supports aliases and doesn't require explicit trait instantiations, making it possible to right such generic code with much less boilerplate.

[pjmlp]

System languages on the Algol/Wirth branch prove otherwise.

They can be ergonomic high level, while providing the language features to go low level when needed.

[singularity2001]

>>> I'm not convinced much could have been done about it.

Are you sure? What stops Swift with its beautiful syntax and safe optionals from becoming a systems language?

[Animats]

The main Rust syntax is OK, but as the author points out, macros are a mess.

The "cfg" directive is closer to the syntax used in ".toml" files than to Rust itself, because some of the same configuration info appears in both places. The author is doing something with non-portable cross platform code, and apparently needs more configuration dependencies than most.

[cies]

Maybe we've reached the limits of the complexity we can handle in a simple text-based language and should develop future languages with IDEs in mind. IDEs can hide some of the complexity for us, and give access to it only when you are digging into the details.

[LAC-Tech]

People seem allergic to anything that isn't superficially ALGOL like. I still remember Facebook had to wrap Ocaml in curly braces because it would apparently blow peoples minds.

[singularity2001]

I think making things syntactically explicit which are core concepts is stupid:

```pub fn horror()->Result{Ok(Result(mut &self))}```

A function returns a Result. This concept in Rust is so ubiquitous that it should be a first class citizen. It should, under all circumstances, be syntactically implicit:

```pub fn better->self```

No matter what it takes to make the compiler smarter.

[SemanticStrengh]

What kind of meaningful data is passed (besides lifetimes) that isn't passed in Kotlin or scala 3 extension methods?

[fulafel]

From the modern systems programming languages set, Go does better in this respect. But admittedly it doesn't reach to quite as low in fitness for low level programming as Rust.

[bilkow]

It looks like I'm on the minority here, but I generally like Rust's syntax and think it's pretty readable.

Of course, when you use generics, lifetimes, closures, etc, all on the same line it can become hard to read. But on my experience on "high level" application code, it isn't usually like that. The hardest thing to grep at first for me, coming from python, was the :: for navigating namespaces/modules.

I also find functional style a lot easier to read than Python, because of chaining (dot notation) and the closure syntax.

Python:

    array = [1, 0, 2, 3]
    new_array = map(
        lambda x: x * 2,
        filter(
            lambda x: x != 0,
            array
        )
    )

Rust:

    let array = [1, 0, 2, 3];
    let new_vec: Vec<_> = array.into_iter()
        .filter(|&x| x != 0)
        .map(|x| x * 2)
        .collect();

I mean, I kind of agree to the criticism, specially when it comes to macros and lifetimes, but I also feel like that's more applicable for low level code or code that uses lots of features that just aren't available in e.g. C, Python or Go.

Edit: Collected iterator into Vec

[klodolph]

There are people who write Python code like that, but it's an extreme minority. Here's the more likely way:

    array = [1, 0, 2, 3]
    new_array = [x * 2 for x in array
                 if x != 0]

Just as a matter of style, few Python programmers will use lambda outside something like this:

    array = [...]
    arry.sort(key=lambda ...)

[nemothekid]

1. I don't think your Python example if fair. I think

    new_array = [x*2 for x in array if x != 0]

is much more common.

2. In your example, `new_array` is an iterator; if you need to transform that into an actual container, your rust code becomes:

   let new_array = array.into_iter()
        .filter(|&x| x != 0)
        .map(|x| x * 2)
        .collect::<Vec<_>>();

And there your generic types rear their ugly head, compared to the one liner in python.

[the__alchemist]

I think part of this comes down to: Does your Rust code make heavy use of generics? I find myself deliberately avoiding generics and libraries that use them, due to the complexity they add. Not just syntactic noise, but complicated APIs that must be explicitly documented; rust Doc is ineffective with documenting what arguments are accepted in functions and structs that use generics.

See also: Async.

[Too]

I want to like rust but the fact that there are replies with 9 different ways to write that loop posted here alone, and no consensus on which one is the idiomatic, is not a good sign.

[rajman187]

minor point but your python code creates a generator here not an array, you'd have to wrap it in a `list()` to get the same data type and be able to for example assert its length (of course you can just iterate over the generator)

[xigoi]

You can only do this chaining when everything happens to be a method. Compare to Nim or D, where you can chain arbitrary procedures like this.

[NoGravitas]

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read.

I'm not sure this is a superficial complaint. People say the hard thing about learning Rust is the new concepts, but I haven't found that to be true at all. The concepts are easy, but the combinatorial explosion of syntax that supports them is untenable.

[sidlls]

Back when I wrote C and C++ for a living I'd occasionally meet someone who thought their ability to employ the spiral rule or parse a particularly dense template construct meant they were a genius. I get the same vibe from certain other groups in this industry, most recently from functional programmers and Rust afficionados, for example. Nobody gives a damn if you can narrate a C spiral or a functional-like Rust idiom.

And this syntax density is one of the reasons I stopped advocating for the use of Rust in our systems. First, I don't want to work with languages that attract this kind of person. Second, I don't want to work with languages that require a relatively heavy cognitive load on simply reading the lines of the source code. Units of code (i.e. statements, functions, structures and modules) are already a cognitive load--and the more important one. Any extra bit I have to supply to simply parsing the symbols is a distraction.

"You get used to it," "with practice it fades to the background," etc. are responses I've seen in these comments, and more generally when this issue comes up. They're inaccurate at best, and often simply another way the above mentioned "geniuses" manifest that particular personality flaw. No, thank you. I'll pass.

[perrygeo]

It's not a superficial complaint but it is relative to one's experience. Something that's "difficult" for me might be "easy" for you and vice versa. I find it very much related to understanding the core concepts.

I personally find Rust syntax to be quite enjoyable, or at least it fades into the background quickly - with a few exceptions. The syntax for lifetime annotations can be challenging. And not surprisingly explicit lifetime annotations are a rather unique concept, at least among mainstream languages. IOW the syntax is difficult because it's an entirely new mental model (for me), not because `<'a>` is an inherently bad way to express it.

[voidhorse]

I wholeheartedly agree that rust’s syntax is way noisier and uglier than I’d like, and it’s nice to see someone else raise the point seriously. People tend to act like syntax is an ancillary detail in a language, but actually it’s fundamental! It’s our direct interface into the language itself and if it’s painful to read and write the language won’t be pleasant to use, no matter how great it’s semantics may be.

Beyond the line noise problem. I feel some of rust’s syntactic choices are confusing. For instance:

let x = 2

Introduces a new name and binds it to the value 2 while

if let Some(x) = y

Is a shorthand for pattern matching. Meanwhile other matching structures have no need of “let” at all. Likewise this extends the semantics of what “if” means and also overloads “=“ (e.g, glancing at this, would you say equals is binding a value to a pattern, performing a Boolean check, or both?) Rust has a couple of one-off weird syntactical devices that have been introduced as shorthand that imo quickly increase the cognitive load required to read code because several structures and keywords are reused in slightly different ways to mean entirely different things.

There are a lot of similar syntactic hoops around type signatures because they didn’t go with the old “type variables must be lowercase” rule which leads to subtle potential ambiguities in parsing T as a variable or proper type in some cases that thus forces additional syntax on the user.

I also think there are too many ways to express equivalent things in Rust, which again leads to more cognitive overhead. Reading the current docs, I get the sense the language is becoming “write biased”. Whenever they introduce some syntactic shortcut the justification is to save typing and eliminate small amounts of repetition, which is great in theory but now we have N ways of writing and reading the same thing which quickly makes code hard to grok efficiently imo.

This minor gripe comes with the big caveat that it remains probably the most interesting language to become vogue since Haskell.

[est31]

I wonder what the author means by the alloc crate not being stable? The alloc crate is stable since 1.36.0: https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...

Regarding the reproducible builds concern around paths being integrated into the binary, a flag exists to get rid of paths: --remap-path-prefix

https://doc.rust-lang.org/rustc/command-line-arguments.html#...

On nightly, there is also remap-cwd-prefix added by the chromium team to address some of the shortcomings with remap-path-prefix: https://github.com/rust-lang/rust/issues/89434

Overall I'm really impressed that an individual wrote 100 thousand lines of Rust. That's a lot!

[jacquesm]

Absolute gold this article.

"In the long term, the philosophy behind Xous is that eventually it should “get good enough”, at which point we should stop futzing with it."

I wished more people would get this.

[ReactiveJelly]

> I wrote a small tool called `crate-scraper` which downloads the source package for every source specified in our Cargo.toml file, and stores them locally so we can have a snapshot of the code used to build a Xous release.

I thought `cargo vendor` already did this?

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

> This cargo subcommand will vendor all crates.io and git dependencies for a project into the specified directory at <path>. After this command completes the vendor directory specified by <path> will contain all remote sources from dependencies specified.

Maybe he doesn't want to depend on Cargo. Fair enough, it's a big program.

[ducktective]

About the installation method ('hi! download this random shell script and execute it'), I agree this is really dangerous but mere installing stuff is a hairy thing on linux distros. I mean what is the practical alternative? Distro package manager versions are almost always way behind.

NixOS/guix are gonna solve this issue once and for all (famous last words)

[wiz21c]

FTA : "This is the point at which Rust’s very strict typing and borrow checker converts from a productivity liability into a productivity asset."

that's what rust is about in my own experience. Especially with threads.

[beardicus]

bunnie is so kind and thoughtful, even when being critical. compare this to the typical frothy-mouthed 'rant' format we see here.

i'm sure rants are cathartic for the writer, but i rarely find them compelling.

[throwaway17_17]

‘Before [const generic], Rust had no native ability to deal with arrays bigger than 32 elements’.

Is this a correct statement? I have seen posts talking about const generics being a new thing as of 2022. Did Rust actually lack the ability to have an array with more than 32 elements? I find it hard to believe that there was no way to have an array of longer length and Rust still being a production level language.

[collaborative]

I experimented with replacing an Express server with Rust while keeping the same js syntax and still running on Node

Granted this adds overhead, but my conclusion was that the performance gain is not worth the effort. Sure, memory looks almost flat but response times aren't that much better

https://github.com/javieranton-zz/warp_like_express

[bfrog]

Very cool, and it’s true Rust is dense. On the other hand C, the other typical option, either requires massive amounts of ancillary tooling and macros like Zephyr to get even close to doing as much at compile time. Those tools and macros add density and complexity. Arguably C++ is about equivalent with fewer pros over C and plenty of the cons of C still there along with some new ones.

I appreciate the idea of trying to create a auditable OS for an MMU capable CPU, the reality is once you have feature you care about that becomes harder and harder it seems.

[ArdelleF]

We do a lot of Rust compilation exploration during the development of TiKV(github.com/tikv/tikv), a lot of interesting learnings ... https://en.pingcap.com/blog/rust-huge-compilation-units/

[_wldu]

Once rust stabilizes, I think it needs an ISO standard like C and C++ have. I can't see automobile manufactures using rust without one. One reason C and C++ are still widely used is due to this. When we are writing code that is expected to run for decades, having a corporate/community backed language is not sufficient. We need global standards and versions that we can rely on decades latter.

[sim7c00]

really interesting read, and nice to see people writing operating systems on rust and have also plus points besides grievances. particularly enjoyed you found rust sometimes spares you the 'damn i need to rewrite this entire thing' tour that C always hits me with :D. now i am more hopeful my re-write-the-entire-thing-in-rust was an ok'ish choice.

[secondcoming]

This was a very interesting read.

IMO the author underplays the visual ugliness of some Rust code. Programmers tend to look at code for hours a day for years, and so it should not be visually taxing to read and parse. This is why syntax highlighting exists, after all.

But the gist I got from it is that Rust is really a very good static analyser.

[cek]

As I was reading the article (in which I learned a ton about Rust, of which I know little), I kept thinking "I know that guy!".

Then I realized the OP was THE "Bunnie" of Xbox reverse engineering fame [1]. <3

[1] https://en.wikipedia.org/wiki/Andrew_Huang_(hacker)

[dgan]

> 100k LOC over two years

Dude wrote more code per week than me in last 6 month at daily job