Hacker News Reader

Comment by nullc | Hacker News Reader

I'm getting an increasingly bad taste from rust. In spite of the hype 9 out of 10 rust programs I download end up with a panic in my first 10 minutes of using them.

Javascript is a memory safe language yet there is plenty of broken code written it it.

Memory safety is a critical step forward but its wasted if it's paired with an ecosystem that thinks memory safety means that software doesn't need to be correct or is so fixated on reimplementing things for "memory safety" that understanding the problem domain and actually making things that work falls by the wayside.

View on HN

Interestingly, I have had the polar opposite experience. When using apps written in scripting languages like Python, I almost expect them to crash at some point because I've seen it happen so often. On the other hand, Rust applications, much like Go, Haskell or C++ applications, in my experience, generally do what they are told without any hiccups.

Care to name some of the "9 out of 10" programs that crashed for you?

> 9 out of 10 rust programs I download end up with a panic in my first 10 minutes of using them.

Do you have some examples? Firefox, ripgrep and fd are the only programs I use that I know are written in rust (I know only a small part of Firefox is in Rust), and they work fine for me

Also bat, the alternative to cat, is written in rust, works fine for me.

Sounds like a completely made up story really. Where would he find ~20 odd rust programs to download and try to report such a stat?

Note that the use of the word "panic" in Rust can be a bit misleading. It is not equivalent to a segfault in C/C++ but rather to a volontarily uncaught exception, killing the application.

It's that kind of thinking that likely contributes to the low software quality.

The software failed and did so in a user uninformative way.

Except in things like network facing software or whatnot --where a segfault might also be an RCE--, a panic is not superior to a segfault. A panic can even still be a vulnerability: DOS attacks are attacks too.

That the failure isn't one that could have resulted in an RCE is only a small consolation in cases where the software doesn't have remote exposure.

There's also just not that much Rust software out there, and 80% of everything is crap. If you compare the best, say, C tool to do something against the best Rust tool, the odds that the Rust tool will be lower-quality are higher - the Rust tool is probably the only Rust tool written to do that, while the C tool is probably the best C tool that's survived over the years.

As someone who has worked with a lot of Rust libraries and applications, your estimate on quality is completely made up hyperbole with the clear intention of maligning Rust.

I have experienced far more success in using Rust and its library ecosystem than I ever have in other languages.

Yes there are bugs in somethings, yes there are others that don’t follow best practices, but throwing out a number of “80%” completely dismisses how solid and capable so many pieces of Rust software are.

Woah, woah, hold on. I'm just referencing https://en.m.wikipedia.org/wiki/Sturgeon%27s_law here.

As somebody who has written a lot of cruddy, unmaintained Rust library bindings because I needed them for a project, I'm speaking, in no small part, about my own work here. Sorry if that wasn't clear.

90% of everything is crap- C or Rust- because there are a whole lot more low-effort libraries and tools than high-quality, maintained, documented ones. There's less Rust code, so the low-effort tools are more visible.

Rust is my favorite programming language, and I use it for everything where a REPL isn't critical (there Python still wins) unless other factors prevent the use of Rust, like the need to work with others or run on weird embedded architectures. I've been writing Rust since before 1.0, was at the 1.0 launch party in SF, and even contributed the (hilariously small, but) std::iter::once API.

So- my intention was "clearly" to malign Rust? Well, actually, it was to defend it. Again, sorry if that wasn't clear, but ...assume good faith next time! Please!

We can agree that there is a lot of low effort stuff out there. But there’s also a ton a high quality rock solid software written in Rust.

Your comment sounded dismissive of Rust, and even reading it again, I still don’t see it as defending Rust. Glad you set the record straight.

Thank you.

Not to discredit you, but you postulate things like "9 out of 10 times" and generally "low software quality" but don't support your statements. It certainly is not my experience that this is (more, or at all) common in the Rust ecosystem.

If an application author uses things like unwrap or expect (two of the most common ways to abort the program with a panic) that is indeed lazy software engineering. But these are also one of the first things that are called out when an inexperienced Rust user asks for feedback on their program in the forum, so should be quite uncommon in any program which is more than a toy or prototype.

Again, not to say that you did not experience this, but just pointing out that it is definitely neither idiomatic nor usual practice.

Edit: There is indeed one point where the Rust community could do better to further reduce the number of panic-ing operations: Some time ago, it was not easy to use the error propagation operator "?" in documentation examples, so some documentation still shows examples which make use of expect or unwrap, possibly guiding inexperienced users towards a bad style. Those will hopefully vanish more or less completely in the near future.

> lazy software engineering

For production code, I agree with you. When writing PoC software, using those can speed up development, rather than forcing you to figure out the best way to deal with those options or errors upfront. Refactoring in Rust tends to also make it reliably produce production quality code when you go back and fix all that.

On the “?” In examples, that can also lead to annoyance for a new to Rust Dev, getting error return types correct, or knowing to leverage crates like anyhow, can be complex at first. Unwrap and expect are great ways to get started. I also make heavy use of them in test code.

Oh yeah absolutely, for prototypes you can liberally use unwrap/expect to figure out the happy path first and remove those calls later.

I haven't checked out the Rust book in quite some time, but it would be cool to make newcomers comfortable with the Result<..., Box<dyn Error>> return type early on, so they know what they have to do to make code containing "?" compile.

I do have a list of 10. I don't really feel comfortable posting it because I don't want to shame people, and also because it will guarantee a bunch of no-true-scottsman, "X, Y, and Z were student projects and Q was just a demo and R only panic because cargo built a debug build by default and there was an integer overflow, and M was only because I didn't provide all the required command-line arguments...".

All those things are true, but my experience, in practice, is that the overwhelming majority of rust things I have attempted to use are broken out of the gate in a way that software written in C/C++ is usually not. I'm glad to hear that not everyone has had that experience-- I did kind of wonder if my comment was going to trigger one of those things where everyone has had the same experience but no one talks about it until someone breaks the ice--, but I have also heard other people express experiences similar to mine the experience is jarring particularly because of the hyped context that rust is usually discussed in.

> still shows examples which make use of expect or unwrap,

right, or older code which is full of unwrap from top to bottom. :)

>in a way that software written in C/C++ is usually not

This is the part that seems odd, more than your experience with Rust. How could you possibly generalize based on an unspecified sampling method across "software written in C/C++"? It's like referring to the typical quality of scientific papers written in English.

A panic is superior to a segfault, because panics can (and should — if they don’t, then yes, that’s lazy) include a programmer-specified error message. A segfault just says “oops” (and a hopefully a stack trace in both cases).

I mean, yes, if a program can recover, it should, but in the case of “error and quit”, panic is an improvement over segfault.

Rust software is of consistently higher quality than most C/C++ software that I use, both in terms of reliability and in terms of UX. I don’t know where you’re getting your claims from.

> The software failed and did so in a user uninformative way.

How is this different to any other crash in terms of user information? Whether it segfault or panics is just as uninformative.

Ignoring vulnerabilities here, a SEGV catches memory bugs, but it can only catch those that result in accessing an invalid region of memory. There's plenty of memory bugs that do not result in a SEGV and instead just corrupt the program state possibly causing all kinds of damage. eg. if `rm` had a memory bug with the paths it read it could be catastrophic. Safe rust prevents all those memory bugs, instead causing a panic. I don't know about you but I'd much rather have a program panic than continue running in an invalid/corrupted state.

> Safe rust prevents all those memory bugs, instead causing a panic.

Rust is even stronger than that, in the vast majority of cases, panics are not related to memory bugs as those are caught at compile time in Rust (panics are usually the quick and dirty way to deal with invalid files names and such things, as Rust refuses to accept those silently).

> panics are usually the quick and dirty way to deal with invalid files names and such things, as Rust refuses to accept those silently

And if you were writing quick and dirty C those would likely be memory bugs instead.

In C the program implicitly assumes there won't be an invalid file name or such thing. If the assumption turns out to be wrong, something unexpected (which may or may not be a memory bug) happens.

In Rust the program explicitly expects there to be an invalid file name or such thing and explicitly panics. This is both safer and more deterministic than C. Additionally, it's easy to grep for things like `panic!`, `unwrap`, `expect`, `unimplemented!`, `todo!`, etc. in your own code or your dependencies' code (assuming you have access to the source). Panicking code also tends to stand out like a sore tooth during code review.

Finally, Rust's approach slightly decreases the odds that someone will be sloppy in the first place. Since you have to explicitly acknowledge the issue and handle it (even if simply by saying `.unwrap()`), there's a chance you'll decide to just handle it properly even though you wouldn't have bothered in C. This is especially the case if you could've handled it properly by shortening `unwrap()` to `?`.

Care to back up your claim with some evidence?

Are you sure this isn't just confirmation bias? When a program "panics" then its easy to conclude that it must be a Rust program but if it doesn't then aren't you simply forgetting to count all the working Rust programs?

>Javascript is a memory safe language yet there is plenty of broken code written it it.

Rust has a lot of safety features javascript doesn't, like lack of null, and data race protection..and types. But the biggest difference is Rust gets you memory safety AND C/C++ performance.

Reply on news.ycombinator.com