Unsafe Rust is harder than C

Maybe this depends on the application type. I've written a lot of each, and maintaining anything involving concurrency is worlds easier in Rust, since those tend to be the most painful and time-consuming bugs to fix. It's got a learning curve, isn't a particularly easy language, and a big chunk of the "community" sucks, but most of the places I've applied it have been a net hassle savings.

twoodfin• 2 years ago

Coming from a position of extreme Rust ignorance & C++ brain poisoning:

Here’s the issue: waiting_for_elements is a Vec<Waker>. The channel cannot know how many tasks are blocked, so we can’t use a fixed-size array. Using a Vec means we allocate memory every time we queue a waker. And that allocation is taken and released every time we have to wake.

Why isn't a structure that does amortized allocation an option here? I appreciate the design goal was "no allocations in steady-state", but that's what you'd expect if you were using C++'s std::vector: After a while the reserved space for the vector gets "big enough".

maxbrunsfeld• 2 years ago

I had the same question. I would think that with rust’s Vec, no allocation would occur at steady state. Vec does not automatically resize when removing elements.

makapuf• 2 years ago

Yup, you can even pre-allocate a given vec capacity to not start zero-sized.

chadaustin• 2 years ago

I'm sorry, I had a whole section on amortized allocation in a draft version of the post but I deleted it, thinking it was tangential. You're not the first person to ask: https://www.reddit.com/r/rust/comments/1gbqy6c/comment/ltonq...

And my response: https://www.reddit.com/r/rust/comments/1gbqy6c/comment/ltpv0...

One typical approach is double-buffering the allocation but it doesn't work here because you need to pull out the waker list to call `wake()` outside of the mutex. You could try to put the allocation back, but you have to acquire the lock again.

I had an implementation that kept a lock-free waker pool around https://docs.rs/wakerpool/latest/wakerpool/ but now you're paying for atomics too, and it felt like this was all a workaround for a deficiency in the language.

Intrusive lists are the "correct" data structure, so I kept pushing.

Analemma_• 2 years ago

Yeah, I'm also not sure what the author is talking about, std::vec also does amortized allocation and never shrinks. There are a bevy of more complicated vector classes in Rust if you need different behaviors, but off the top of my head I don't know why std::vec wouldn't work here.

melodyogonna3• 2 years ago

Rust is harder than C

OtomotO7• 2 years ago

To me C is much, much harder than Rust.

I've written both, albeit way more Rust.

melodyogonna3• 2 years ago

What makes C much much harder? What concepts exist in C and are not present in Rust?

kelnos7• 2 years ago

C is easier to write, Rust is easier to write correctly.

melodyogonna3• 2 years ago

Rust is also hard to write correctly. You just pay the complexity costs at different times in both languages - in Rust you make a lot of upfront investment.

tapirl• 2 years ago

Rust is harder than C++. It is C+++.

dgfitz• 2 years ago

For me, it really is just so much syntax and mental overhead to track. Somehow it seems like the same goals could have been accomplished with less verbosity.

It almost feels like an engineering tool/language, by devs for devs, instead of by devs for “customers” where customer == “outside” devs, of which I am one.

Edit: typo

wongarsu• 2 years ago

Unsafe Rust is significantly harder than C, with complex rules that are not fully specified. But luckily you don't have to write a lot of it. And the bit you need can either come from battle-tested libraries or be contained to it's own module where you can rigorously test and fuzz it. And the tooling available for that is pretty good. The article shows good examples of that.

There is some work on making unsafe rust safer, or at least easier to get right. But those are significant undertakings that will take years to pay off.

On the other hand safe rust is so much easier than correct C that I don't particularly mind the tradeoff.

kazinator13• 2 years ago

Safe Rust looks absolutely painful painful compared to other safe languages.

Correct C is not actually hard to write. It can be somewhat hard to convince oneself that it's right.

That's an important difference. Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine.

Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems.

tptacek2• 2 years ago

When people talk about not needing to write much unsafe Rust, they mean that in any large-scale system, there are probably only a couple hotspots that are complicated enough to need the escape hatch from the Rust safety rules; you write the unsafe code, you give it an interface to the rest of the code, you carefully validate the unsafe code, and you're good to go.

They don't mean that you write unsafe Rust code for experimental or exploratory code that will be thrown away. You could do that, but it's not common.

More importantly: this approach of parsimoniously writing unsafe code in a larger-scale safe system does not work in C/C++. Memory safety issues can (and do) crop up all over your system, not just in the small "unsafe" parts you validate carefully.

steveklabnik8• 2 years ago

Safe Rust takes some time to learn, but once you do, is quite pleasant to write. It is true that it takes some time to get over that hump though. Google found that it was three to six months, but after that, there was no productivity penalty.

Rust offers tons of tools that are very useful for correctness outside of memory safety. I hope to never program in a language without sum types ever again, if possible.

kelnos7• 2 years ago

Correct C is not actually hard to write.

Ugh, not this again. Yes it is. It's hard. Veteran C programmers (I include myself in this category), even with compiler warnings, linters, and address sanitizers, still make mistakes all the time.

Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine.

So what? That's not the kind of code we're talking about.

Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems.

That's either whataboutism or a straw man. No one is claiming that languages that help avoid common C memory-related bugs like out-of-bounds access, use-after-free, memory leaks, etc. will also somehow magically make all your logic errors go away too.

stouset3• 2 years ago

Safe Rust looks absolutely painful painful compared to other safe languages.

It really isn't. It's quite nice to use. The big hangup is that Rust "wants" you to structure your programs according to a certain philosophy. Unfortunately the compiler can't teach you that approach directly, but can only complain when you write programs that don't abide by it.

In my experience, following this design philosophy benefits even outside of memory safety, and I now write code following these principles in every language.

Correct C is not actually hard to write.

Quite literally all of the available evidence strongly disagrees with this conclusion.

Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems.

This is true, but C lack tools to help with any of them. Fixing memory safety and overflows is in and of itself an enormous win, but Rust also has other tools that assist in program correctness (sum types being a huge one).

rowanG0773• 2 years ago

Correct C is not actually hard to write.

I would advise to you not say such blatantly false things. You paint yourself either as a liar or as unqualified. C has been proven time and time again to be almost impossible to write correctly. Even top tier programmers like djb cannot write safe C.

signa11• 2 years ago

yup, after some experience, memory safety becomes kinda easy to get right.

integer safety on the other hand is pretty hard, and non-trivial to get right unfortunately.

f1shy2• 2 years ago

There are two big commandments of the modern programming religion:

- Type safety

- "Memory safety"

We have to understand it: it is religion. No science.

in 10 years maybe somebody start realising, that even with the 2 sw can still be very bad. And those 2 are not silver bullets... until then... patience.

WalterBright• 2 years ago

On the other hand safe rust is so much easier than correct C that I don't particularly mind the tradeoff.

D isn't Rust, but my personal style has gravitated towards the borrow checker rules anyway. It wouldn't be hard at all to do it in C, either.

C's biggest security failing, however, is the lack of array bounds checking. It's always the #1 cause of security bugs in the field, by a wide margin. None of the workarounds in Standard C are attractive. I do not understand why the C committee adds all these bits and pieces of new features, and does not fix that problem. It's not like it's hard:

https://www.digitalmars.com/articles/C-biggest-mistake.html

The solution has been out there for 15 years now.

Gibbon1• 2 years ago

The standards people won't even add a standard buffer or slice to the language.

I kinda cry every time I see a new api with foo(void *src, int sz) signatures.

kelnos7• 2 years ago

It sounds like this boils down to one thing: C and Rust have different aliasing rules, with Rust's being much more restrictive.

You can't assume programming in unsafe Rust is like programming in C. Unsafe doesn't mean "do whatever you want"; it means you get to do things that the compiler won't check for you, but it's your responsibility to ensure you're still maintaining Rust's invariants.

So yes, unsafe Rust is harder than C. I think that's fine, though. Most people will be able to get by without writing any unsafe Rust, and those who still need to use it will end up writing very little of it. And tools like MIRI exist to help increase your confidence that your unsafe Rust is correct.

jsheard2• 2 years ago

C and Rust have different aliasing rules, with Rust's being much more restrictive.

Rust is more restrictive by default, but C's restrict keyword lets you opt-in to strict aliasing semantics in exchange for unlocking compiler optimizations that would otherwise be unsound, so it's not like you're free from having to think about aliasing in high performance C code.

kelnos7• 2 years ago

Agreed, but in practice defaults do matter, and it's pretty rare that I see a C code base that actually makes use of 'restrict' etc. It's nice to see it sprinkled liberally throughout glibc's headers, but that's the exception, not the rule.

steveklabnik8• 2 years ago

It's not so much "more restrictive" as it is "just plain different."

You have behaviors for all four quadrants: there's stuff that's okay in Rust and not okay in C, stuff that's okay in both, stuff that's not okay in both, and stuff that's not okay in Rust and is okay in C.

bloppe• 2 years ago

Very curious to know an example of what's ok in Rust but not in C

andrewmcwatters• 2 years ago

I feel a sort of professional obligation to learn the cryptic unnecessary glyphs and runes that Rust and its ilk proliferate all for this important concept that is memory safety.

However, I would much rather that more languages like Go and Zig simply take off in popularity instead, and that we just reject the eyesore and cognitive mess that is Rust syntax. It’s a language which has no regard for beauty.

jcrites• 2 years ago

For what it's worth, I disagree. I think it would be difficult to design a language more elegant than Rust while accomplishing the same goals. Maybe those goals aren't ones that everyone cares about, and that's OK.

It's a language that's definitely worth learning; it expands the mind in a way that languages like Go (or Java, or any GC language) will not. There is a great beauty and elegance to its design.

OtomotO7• 2 years ago

I would love a much simpler Rust...a Zig with a borrowchecker, a small stdlib (like Rust), some official package manager.

I agree that Rust has a lot of syntactic warts but the common stuff I find beautiful

MarkSweep• 2 years ago

As long as we counting Go as an alternative to Rust, there are a whole host of other garbage collected languages that provide memory safety benefits compared to the status quo of C and C++. Languages like Ruby, Java, Python, C#, and PHP.

Personally I don’t think it makes sense to write all software in Rust. A GC makes it much easier to write certain patterns that are frustrating to write in Rust.

fjasdyfs• 2 years ago

I agree the syntax in Rust can be hairy however presenting Go as an alternative to Rust makes zero sense. They have completely different runtime characteristics and goals.

sgt• 2 years ago

Can't wait for Swift to gain traction in systems programming.

agentultra2• 2 years ago

Using a Vec means we allocate memory every time we queue a waker. And that allocation is taken and released every time we have to wake.

Is that so? On every push back? I’d expect it’d only do an allocation when the current array segment is almost full… as a vector you might write by hand or like the ones in the C++ standard libraries do.

raptorfactor• 2 years ago

This surprised me too, so I checked: https://doc.rust-lang.org/std/vec/struct.Vec.html#capacity-a...

"Vec does not guarantee any particular growth strategy when reallocating when full, nor when reserve is called. The current strategy is basic and it may prove desirable to use a non-constant growth factor. Whatever strategy is used will of course guarantee O(1) amortized push."

Seems it should be amortized just like in C++?

agentultra2• 2 years ago

I don't want to tell the Rust folks what they should do but as a potential user I'd be more interested in the language if it was explicit (or the rules we clear and deterministic at the least). This claim took me a bit by surprise and I'd be upset if I'd encountered it in production code.

Sytten• 2 years ago

Most of the complexity comes from the fact that all types are moveable by default. That is why I prefer this proposal to make it opt-in [1]. Working with pin really sucks the joy out of you and it won't be some sugar syntax (the current &pin mut proposal) that will help that. Rust is a fine language most of the time, but sometimes like the author you fall in rabbit holes.

[1] https://smallcultfollowing.com/babysteps/blog/2024/10/14/ove...

codewiz• 2 years ago

The very last line: "Putting this in words was as hard as writing the code."

Unsafe Rust is harder than C

Related Stories