[uecker]

There is Rust code I saw that was cluttered with "unsafe block" to an extend that I am a bit skeptical there was meaningful memory safety left.. There is C code which is nicely structured where I have more confidence in. I am also skeptical about the overall complexity of Rust and I think cargo is "nasty" because of supply chain risk, proliferation of dependencies. So I do not believe for a second the gap between C and Rust so big Rust proponents want us to believe.

[anon-3988]

> There is Rust code I saw that was cluttered with "unsafe block" to an extend that I am a bit skeptical there was meaningful memory safety left.. There is C code which is nicely structured where I have more confidence in.

This is anecdotal but I have seen FAR more nasty C code than I have Rust. I can probably count using all my fingers and toes the number of times I have seen and have to vet unsafe code.

I spent a week vetting a WebSocket implementation in C to not have buffer overflows, memory leak, use-after-free, overflow, etc etc before I even start vetting the logic. They also have their own bespoke async library so I have to make sense of that first too.

I spent a day looking at WebSocket implementation in Rust exactly because I don't have to worry about stuff like is this void* reliable and following the call stack to make sure it makes sense.

> I am also skeptical about the overall complexity of Rust and I think cargo is "nasty" because of supply chain risk, proliferation of dependencies

I am curious how C solves this problem, if you need a btree, a JSON parser, a tree-sitter, a string with SSO optimization; where do you get this? Write your own? Vendor some packages? Rely on the package manager?

They all have the same issue of there's simply too many code to vet.

[whytevuhuni]

> They all have the same issue of there's simply too many code to vet.

The problem is not the amount of code to vet, it's the amount of people who own it, and thus the amount of people I need to trust.

In C, I use a "standard library" replacement like GLib or APR, and if they don't have what I need, then I implement it myself. Thus, the number of owners is just 2.

Is my own code less trustworthy? For a start, of course. But once I fix it, once a tool becomes stable, it stays fixed, in the face of all future dependency updates.

[anon-3988]

I don't see why you can't do this with Rust? If you want to use your own internet checksum implementation that doesn't draw in "random dependencies" for simd or whatever else. You are free to implement, verify and optimize your own.

[whytevuhuni]

It's not possible to do with crates.io because of the culture it has.

When I pull in GLib, APR, libuv, etc as a dependency, that is literally the only dependency. They depend on glibc, maybe libpthread/libm, and nothing else.

When I pull in tokio, I now have 40 dependencies.

[whytevuhuni]

I'm being a bit unfair to tokio, since they seem to actually be trying really hard to keep their dependencies down.

But I'll stick to my belief, as that seems more unusual than usual to me, for crates.io libraries in general. C has a culture of minimalism. Rust has a culture of easy of use. The latter is a nightmare for trust.

[timschmidt]

Cargo being part of the language has lowered the barrier for code re-use. This is a good thing. And the reason Rust libraries seem to be more granular and numerous than C or C++ libraries which seem to conglomerate into monstrosities like Boost. Cargo allows for pinning dependencies, vendoring dependencies, and even the dependencies of dependencies.

Supply chain attacks are real threats however, which plague any language with or without a package manager (see the XZ backdoor for a great example of a supply chain attack in C). Rust projects may have many more dependencies than C projects, but that's precisely because each is smaller and easier to verify, because Cargo makes integrating many libraries easier than the process has been historically for C/C++.

[whytevuhuni]

> There is Rust code I saw that was cluttered with "unsafe block" to an extend that I am a bit skeptical there was meaningful memory safety left..

There certainly is. But is it more than 1% of the Rust code out there?

And let's assume we're talking about a project where it is more than 1%. Let's say there's only 50% safe code (I personally have never seen this, not even in embedded). Is that still not a strict improvement over C?

> I am also skeptical about the overall complexity of Rust

When you're building a small project, using something like C++ or Rust will indeed feel like that.

But when you're building a large project, then using a simple language doesn't make things simpler... it simply moves the complexity elsewhere, and more specifically, into your code.

In that case, consolidating the complexity into a single place (the language) makes it so that this complexity is reusable, you learn it once and you understand all places that use it, even in other projects.

The time it takes to learn, yes, it'll be huge. Afterwards, programming in Rust becomes significantly easier than in C.

> I think cargo is "nasty" because of supply chain risk, proliferation of dependencies.

This one I actually really agree with, and am very sad about it.

[saagarjha]

I invite you to look at how close the C proponents think the gap is.