I Hope Rust Does Not Oxidize Everything

The author seems very anxious because Rust is getting traction and they don't like Rust. They're afraid that one day Rust will become a "monoculture" and everything will be written in it.

I like Rust, but I consider this very, very unlikely.

Rust has actually brought more choice to the programming language scenario. If we're talking about monoculture, let's talk about C/C++. For decades this was the only viable option for systems programming. All new languages were focusing on a higher lever. Languages for lower level stuff were rare. There was D, but it never got enough traction.

Then Rust appeared and there is finally an alternative. And not only that, I because of that, other language designers decided to create new systems languages, and now we have Zig, and Odin, and Vale, etc.

So if anything, Rust is helping in breaking the monoculture, not creating it. C and C++ are not going away, but now we have alternatives.

And I think it's important to acknowledge that even if you don't like a language, if you see a bunch of software being written in such language, it's because the language is useful. I don't like C++ but I admit it's damn useful! People are writing interesting software in Rust because they find it useful.

The author makes the best argument for Rust in the linked post[0]

    Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some.

    I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head.

    This also means that the bigger the language is, the less space I have in my head for the code.

    Rust is too big for my small brain, unfortunately.

Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down. Besides this I disagree with the author's assertion that Rust is not well suited for them, in fact I think it's strictly better than C because it often obviates the need to keep stuff in your head. Take lifetimes, in C you have to keep track of pointers and their lifetime in your head, and by definition all other maintainers have to do the same, in Rust the compiler does that for you, less to keep in your head. In fact I think the ability offload things from your head to the compiler is one of Rust's great strength. This ties in with compile times too, yes Rust is very slow to compile, but the compiler also does a whole lot more work than the C compiler. Obviously we want rustc to be as fast as possible given the work it's doing, but it will never be as fast as a C or Go compiler.

0: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...

Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.

My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. For me it was the opposite. I was getting bored with my industry and thinking of a move to something else like management. Rust came along 6 yeas ago (for me) and threw me a lifeline. I love getting good at something that is hard, it’s just very satisfying. I do get why some people can’t stand the language. It is ugly to look at with its genetics and lifetime annotations and when a project is so large that it begins to lag rust-analyser then my joy turns to rage too.

>the syntax. It’s ugly. [...] I would prefer something that is less sigil-heavy.

That's also one of my gripes with Rust. Very sigil heavy makes it hard to google syntax elements. What's the name of the `|` glyph? Especially challenging if you know the name of the glyphs in your language but not in necessarily in english. Double challenging for glyphs with several accepted names

But in the end, I'm big enough to realize that this is not a very important aspect of the language

If it's ugly so be it. I'll still learn it

Also for once Bing Copilot pretty much solved this for me since unlike google search, it's semantic + it doesn't ignore special characters

I just cloned the Starship repo and cargo --release built it and it took six minutes and 30 seconds (which did feel interminable). The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else".

My CPU is from 2012. What on earth is he doing this on, a TI-83? Or am I missing some intricacy of whatever Gentoo is doing that would inherently inflate build times by an order of magnitude?

People complaining about Rust... As Bjarne Stroustrup says: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"

This is actually the kind signal I wanted to see. A language everyone likes isn't right. In production, programmers have to follow customer requirements, not the other way around, and customers don't care about your pretty code, they want their things to work, and at some point it is going to get ugly, and people will complain. As time goes on, there will be more and more of that ugly legacy code, and you have to keep it, because people are using it, and people will complain more, and they will blame everything that relates to it: the language, customers, management, previous devs, etc... It is actually a good thing, it means the language is used to do real work, you will never get these complains when all people do with it are toy projects or a few precise, programmer driven programs.

> First, the syntax. It’s ugly. TO MY EYES!

Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1]. The decision to please the C++ crowd so much (mainly manifested in later syntax related decisions) would not have been my preference, but it makes sense and there could have been worse decisions.

> Second, Third, Fourth, Fifth

I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community.

> Sixth, Rust doesn’t go far enough in static analysis. Rust had a chance to go much further, and the team blew it.

I am not qualified to judge that, but I am curious of other opinions.

> Seventh, Rust compile times are a joke

True, but this is actively tackled on multiple fronts. One is cranelift, which I find highly fascinating.

[1] https://steveklabnik.com/writing/the-language-strangeness-bu...

The post is a bit of a rant and all over the place. Async infecting everything, ugly syntax (who cares?), slow compile times etc.

What stood out to me:

> In other words, if compilation is fast, the tooling is easy.

Andrew Kelley said something similar in a recent talk. Compiler performance seems to be the number one priority at the moment for Zig.

The rationale seems to be: fast compilation leads to more productivity, which leads to more bugfixes.

This claim seems almost bruteish, but it makes sense.

Tight feedback loops (think things like devops, REPL, TDD, light processes etc.) can help us to iterate more and stay in the zone.

To be fair a sophisticated type checker like Rust‘s also helps with that.

But of course any added friction and sluggishness can be an indirect hindrance to the overall correctness and even performance of a program.

The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust.

You can't even mention that bootstrapping the compiler is a process that's way too convoluted, because you get buried to oblivion ("why would you need that"). Thankfully there are some already, though incomplete because (I'm guessing) Rust being mostly defined as "whatever rustc outputs" doesn't help reduce the pain of checking if your implementation is correct. I appreciate the efforts that are going on to write informal non-spec documentation about the language though, better than nothing.

Also can't mention that alternative compilers would be nice (e.g. to make bootstraping easier, see previous point), because you also get buried to oblivion ("don't fragment the ecosystem", "the Rust council/teams/etc will always be composed of trustworthy people now and forever").

Like, yes, but chill a bit and try to consider other use cases instead of reading those topics as attacks to the language just because you think you don't need them. A small minority being very loud in rejecting any attempt at healthy discussion is not good optics for the ecosystem.

This stuff also happens with other languages' communities, but somehow I seem to find them happening a lot more frequently with Rust.

(P.S.: Changing the topic a bit, I'll invoke Cunningham's Law and say there's no easy way to read Rust documentation offline that doesn't require a web browser of some kind or parsing HTML output. Some equivalent to `go doc` or Python's `help()` function.)

I'll bite: What specific parts of rust syntax do people find so ugly?

I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

This argument is always so divided into very thoroughly mine-protected trenches it’s insane.

The anti-rust crowd treat the language like it has more boilerplate than JavaScript and that it’s the most complex language out there while offering no benefits, which just isn’t true. It’s a great language with a lot of features that are huge advantages over C/C++.

The rust evangelists treat it like it’s the second coming and that you’re literally killing babies if you aren’t letting the language enforce its paradigms on you. The forced safety the language offers is a great feature in 2024, but it is not a be all end all thing - there are plenty places where it just isn’t necessary and creates more work for the programmer. The argument is also usually “everything should be rust” but the moment you point out a use case where its advantages don’t matter, they say “well the rewrites only need to happen for <x critical direct networked service>” - that then means everything doesn’t need to be rust, no?

Like most things, the correct path is somewhere in the middle. I personally don’t like Rust’s syntax, generics, not being object oriented, etc - but that’s just my opinion and is no more valid or invalid than the next. At the end of the day, use the language you like most and are comfortable with, as long as you understand the benefits and drawbacks of each.

- Signed, a Kotlin evangelist

Within Rust is a smaller, simpler, safer language struggling to get out

This is my current mental model for picking a language, considering just the language itself:

- Backends: Gleam or other BEAM

- Web frontend: Gleam

- Mobile apps: Dart + Flutter

- Specialized mobile apps: Swift and Kotlin

- Blazing fast: Zig

- Blazing fast and safest: Rust

- Fast performance and iteration: Go

Would love to hear additions and corrections.

My only problem with this is I'm not a fan of Go's syntax and I wonder what's a good alternative. Heared good things about OCaml but didn't check it out yet.

I have seen a lot of criticism of async Rust.

In C# most APIs expose both sync and async versions of the same methods. Why is that not more common in Rust?

Sure some 3rd party C# libraries probably do some ugly sync to async conversion internally but most don't and use the .NET standard libraries sync/async versions of the same APIs.

Maybe that will sound banal to some but C would be so much more enjoyable to me if it had a "cargo" system and no implicit imports.

I mostly agree. Compile times are the worst in the industry, and async is a mess.

Rust is a systems programming language. It forces you to think about computer architecture as you are writing code. The language is a tool expressing how logic should execute safely and performantly on actual hardware. That is both its strength and weakness.

I agree with the article in so far as the hope that people will not start pushing Rust as the cool language for pretty much everything.

For many development endeavors, the language is a tool purely for expressing logic, and for that Rust is a poor choice IMO.

What does Yao look like? edit ah I found some examples https://rigbuild.dev/yao-tutorial/

"I like small programs with few dependencies. I will write my own I/O to avoid dependencies. And tokio is to dependencies what god objects are to object-oriented programming."

This is what is preventing me from using Rust. It is so tightly integrated with a package manager for libraries that trying to avoid crates.io and dependencies is like paddling against the current.

@gavinhoward Just FYI, a couple of links in the article are broken:

* The "incomplete list" of C UB currently points to the Rust spec vision

* The link labelled "unreasonable programming language" currently points to the Gentoo Wikipedia page

* The "Starship" link points to the House Wiki page on Vicodin

The compile times are the only real issue mentioned here.

I still think it's better than C++ but for large projects the compile times and crate splitting, etc. become a real pain.

Not to author: The URL for the "incomplete list" hyperlink is incorrect.

A lot of this author's complaints about Rust remind me of similar historical complaints about C++, but amplified.

Hijacking and overtaking new projects? C++ and Rust both do that. C++'s compile times were a joke, Rust is even worse. Complex semantics and syntax? Both have those. Rust is trying to be everything to everyone? C++ has always been criticised as design by committee.

And yet C still exists and is widely used. Once the smoke cleared, people simply hated C++ and what it brought. After all was said and done, C became regarded as much more tolerable and usable for lack of those headaches. C++ still exists and there is certainly not a C++ monoculture. I hope and expect that the same story will play out for Rust.

Projects adopting rust makes contributing less fun and more painful

I tried to work on bug fix for Zed, waiting 30 seconds everytime you change a value was _very_ painful

I'm hoping this rust fad goes away soon

Be the change you want to see.

I refuse to use rust for a multitude of reasons.