DEV Community

loading...

It seems like Rust software is bad

Ryan Westlund
I'm a programmer, writer, and philosopher. My Github account is yujiri8; all my content besides code is at yujiri.xyz.
・2 min read

I love Rust. I think it's the single most well-designed language I know, and I want it to be more popular. But I have been constantly disappointed by the quality of everything I find written in Rust.

Fractal is a GTK-based Matrix client written in Rust. I found it when I got interested in Matrix and looked for a desktop-based client that could run on Linux and FreeBSD, and I jumped on it in part because it was written in Rust. I could promote my favorite language and my favorite chat system at the same time.

But time using it has shown me that Fractal sucks. I don't want to blame a group of volunteer open-source devs for being way behind Element on features, but it has also been pretty buggy in the time I've known it and provides a generally poor experience. The bug of being unable to change avatars that it had when I first installed it, the lack of error messages whenever things go wrong (things often just silently don't work), freezing when you scroll upward which has been there since my first day and AFAIK is not fixed, the random crashes, the bizarre levels of CPU usage for who knows what reason...

Every time I find something written in Rust that's comparable to something in another language, the Rust implementation has drastically more lines of code than I expect given the array of powerful abstractions in Rust. The Diesel ORM, far from feature complete, is nearly 60k lines of Rust.

The 3 Crystal ORMs I've checked out, Granite, Clear, and Jennifer, are all 10k lines or less. Given Crystal's pragmatism-before-purity philosophy compared to Rust, I'd expect them to be a little briefer, but not that much.

Another example is the Rust versus Go implementation of Age encryption - 2500 to 6000 lines. I think rage has a few more features, but really? Go is a relatively verbose language.

I wonder to what extent the SLOC counts can be blamed on rustfmt having a much stronger preference for breaking lines. I would think not that much since many people in other languages wrap at 80 cols anyway.

Anyway, I feel a bit disappointed that despite the apparent quality of Rust, the stuff written in it never seems to be of good quality.

Discussion (13)

Collapse
jrop profile image
Jonathan Apodaca

On the contrary: we use Rust where I work, and once we vet our components written in Rust, we find that they are extremely stable. Granted, we are not writing our UI in Rust. There does not seem to be an agreed upon library for that in the community yet.

Collapse
yujiri8 profile image
Ryan Westlund Author

Glad to hear it!

Collapse
entomy profile image
Patrick Kelly

The real key to reliable and well written software is in the process. I've seen a lot of people use Rust as a "magic bullet" the same way people tried to use Ada. It doesn't work. Sure, a good tool helps. But a tool doesn't make you skilled on its own.

Collapse
davidedelpapa profile image
Davide Del Papa

I think comparing SLOC between different languages is not a good metric at all. For example, if in Rust you match a lot, it will increase even up to 200% the line count (or even more). However, the advantages of such a strategy are huge. Just remember that the focus of Rust as opposed to other languages is security, otherwise we could get rid of the borrow checker altogether.
Of course if you write lots of unwrap() the line count gets smaller, but in a library this strategy is not appropriate; therefore the line count gets larger and larger.

Collapse
yujiri8 profile image
Ryan Westlund Author

Those are good points, but at least when comparing to Go I thought it would be meaningful because one of the main things I prefer about Rust over Go is the addition of shorthands to deal with errors.

Collapse
darkoverlordofdata profile image
Bruce Davidson

I feel the same way, but for me, it’s the ecosystem that is really broken. Look for x11 bindings. I prototyped an x11 based screen lock in c, and I’m currently running my ‘beta’, a vala program. I was thinking maybe I should look at rust for the final version, but I find 7 bindings for x11. That’s a lot of code to review and test. So far, none of them actually work, and I’m thinking why not stick with vala? The main reason I was looking at rust is that Gnome has said to prefer rust over vala. But then, I prefer pantheon desktop over gnome.

Rust may be great for some narrowly defined uses, but I don’t think the ecosystem as a whole is ready for general purpose use.

Collapse
yujiri8 profile image
Ryan Westlund Author

Yeah. It may be in part because Rust's design is still undergoing important changes, whereas Go got much more stable earlier. Both languages are similarly new (Go released in 2011 vs Rust in 2012 IIRC) but Rust's ecosystem is more what I'd expect for a language that new, whereas Go's ecosystem already looks like it's been around for as long as Python.

Collapse
phantas0s profile image
Matthieu Cneude

I think programming language and bugs are not that correlated. Knowing a programming language (even very well) is not enough to manage complexity. It's more a question of problem solving skills and the context the app was developed in.

Collapse
alexgnatrow profile image
Alex Row • Edited

This really feels more like a rant imo.
There are bad software engineers.
There are bad software architecture desicions.
And surely 2 examples(havent heard about both of them anyway) are not even start to be close enough to reach such a conclusion.
And even so matrix client with GTK is sooo much depends on the decisions made doings it, which is a tricky part of all chat apps.

So not Rust alone can be the point of failure.
That being said...it not nesessarily can't be!shrug

Collapse
yujiri8 profile image
Ryan Westlund Author

I think you read more into my post than was intended. I am not trying to "reach a conclusion", and I stated that I still love Rust. I'm not claiming that this proves Rust is a bad language. I'm just expressing my disappointment.

Collapse
alexgnatrow profile image
Alex Row

Well its fantastic you wish to stick with Rust a bit longer then :P

Collapse
lamka02sk profile image
lamka02sk

Measuring quality by number of lines is not the brightest idea. Also did you exclude tests and comments? In Rust, they are a much bigger part of the code than in any other language.

Collapse
yujiri8 profile image
Ryan Westlund Author

I think that for similar functionality, number of lines is a pretty good indicator of code quality. The fewer lines, the more maintainable, the fewer bugs.

I always count source code lines with tokei, so it excludes comments and blanks but not tests. I don't know of a good way to exclude tests in these counts.