Earlier quoted context omitted.
Out of curiosity, why do they take raw pointers as arguments, rather than references?
From the RFC: https://rust-lang.github.io/rfcs/2325-stable-simd.html > The standard library will not deviate in naming or type signature of any intrinsic defined by an architecture. I think this makes sense, just like any other intrinsic: unsafe to use directly, but with safe wrappers. I believe that there are also some SIMD things that would have to inherently take raw pointers, as they work on pointers that aren't…
Zlib-rs is faster than C
421–430 of 492 posts
Re: Zlib-rs is faster than C
#422Earlier quoted context omitted.
I think you're misunderstanding of what I'm claiming is being checked. I don't mean the unsafe block directly. I mean that &mut Ts do not alias. That is checked by the compiler. I'm saying that even in a codebase with a lot of unsafe, the checks that are still performed have value.
Sure, but C++ objects returned from operator new are likewise guaranteed not to alias. There's "value" there, but not a lot of value. And I repeat, you're overselling hard here. People who write rust like this are going to produce roughly the same amount of memory safety bugs, and pretending otherwise is frankly dangerous, IMHO.
In c++ i could do something like:
x_ptr = new object y_ptr = x_ptr
copy(x_ptr, y_ptr)
In safe rust there is no way to call the function in question if that sort of aliasing has happened. This means that if you get a bug from your copy, its in the copy method - the possibility it's been used inappropriately has been eliminated.
It reduces the search space for problems from: everywhere that created a pointer that is ultimately used in the copy, to: the copy function itself.
It reduces the number of programmers who have to keep the memory semantics of that copy in their head from "potentially everyone" to just "those who directly implement and check copy".
Pretending that has no value is absurd.
Re: Zlib-rs is faster than C
#423Earlier quoted context omitted.
> a rewrite for “maintainability” is an engineer saying they want to rewrite in their preferred language Not necessarily—sometimes languages are especially poorly suited for tasks or difficult to hire for.
We’re talking about a rust rewrite of a fairly core level library. I don’t think C is inherently unsuitable or difficult to hire for. If the library was in Fortran then maybe. But yes you are technically correct, congratulations.
Obviously the code isn't going anywhere, and obviously we DO have reliable code we've built with C. But acting like C and Rust deliver equivalent value is simply farcical: you choose C for rapid development and cheap devs (or some other niche concern, like using an obscure embedded arch), and you choose rust to solve the problems that C introduced.
Re: Zlib-rs is faster than C
#424Earlier quoted context omitted.
With unsafe you get exactly the same kind of semantics as C, if you don't uphold the invariant the unsafe functions expect, you end up with UB exactly like in C. If you want a clean crash instead on indeterministic behavior, you need to use assert like in C, but it won't save you from compiler optimization removing checks that are deemed useless (again, exactly like in C).
> With unsafe you get exactly the same kind of semantics as C People seem to disagree. Unsafe Rust Is Harder Than C https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41944121
Using raw pointers in unsafe Rust is easier than using raw pointers in C.
The solution is to not manipulate references in unsafe code. The problem is that in old versions of Rust this was tricky. Modern versions of Rust have addressed this by adding first-class facilities for producing pointers without needing temporary references: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#nativ...
Re: Zlib-rs is faster than C
#425Earlier quoted context omitted.
From the RFC: https://rust-lang.github.io/rfcs/2325-stable-simd.html > The standard library will not deviate in naming or type signature of any intrinsic defined by an architecture. I think this makes sense, just like any other intrinsic: unsafe to use directly, but with safe wrappers. I believe that there are also some SIMD things that would have to inherently take raw pointers, as they work on pointers that aren't…
Which also doesn't preclude someone else writing an abstraction on top that provides an API using references.
Re: Zlib-rs is faster than C
#426Earlier quoted context omitted.
Unsafe is a very distinct code smell. Like the hydrogen sulfide added to natural gas to allow folks to smell a gas leak. If you smell it when you're not working on the gas lines, that's a signal.
Someone mentioned to me that for something as simple as a Linked list you have to use unsafe in rust Update its how the std lib does it: https://doc.rust-lang.org/src/alloc/collections/linked_list....
You can implement that linked list just once, audit the unsafe parts extensively, provide a fully safe API to clients, and then just use that safe API in many different places. You don't need thousands of project-specific linked list reimplementations.
Re: Zlib-rs is faster than C
#427Earlier quoted context omitted.
No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness.
Hard disagree - if you violate the invariants in Rust unsafe code, you can cause global problems with local code. You can cause use-after-free, and other borrow checker violations, with incorrect unsafe code. Nothing will flag it, you will have no idea which unsafe code block is causing the isue, debugging will be hard. I have no idea what your definition of encapsulation is, but mine is not this. It's really only en…
Is it? I've written hundreds of thousands of lines of production Rust, and I've only sparingly used unsafe. It's more common in some domains than others, but the observed trend I've seen is for people to aggressively encapsulate unsafe code.
Unsafe Rust is quite difficult to write correctly. (The &mut provenance rules are a bit scary!) But once a safe abstraction has been built around it and the unsafe code has passed Miri, in practice I've seen people be able to not worry about it any more.
By the way I maintain cargo-nextest, and we've added support for Miri to make its runs many times faster [1]. So I'm doing my part here!
Re: Zlib-rs is faster than C
#428If you're writing your program in C, you're afraid of shooting yourself in the foot and introducing security vulnerabilities, so you'll naturally tend to avoid significant refactorings or complicated multithreading unless necessary. If you have Rust's memory safety guarantees, Go's channels and lightweight goroutines, or the access to a test runner from either of those languages, that's suddenly a lot less of a problem.
The compiler guarantees you get won't hurt either. Just to give a simple example, if your Rust function receives an immutable reference to a struct, it can rely on the fact that a member of that struct won't magically be mutated by a call to some random function through spooky action at a distance. It can just keep it on the stack / in a callee-saved register instead of fetching it from memory at every loop iteration, if that's more optimal.
Then there's the easy access to package ecosystems and extensive standard libraries. If there's a super popular do_foo package, you can almost guarantee that it was a bottleneck for somebody at some point, so it's probably optimized to hell and back. It's certainly more optimized than your simple 10-line do_foo function that you would have written in C, because that's easier than dealing with yet another third-party library and whatever build system it uses.
Re: Zlib-rs is faster than C
#429Earlier quoted context omitted.
The encapsulation referred to here is that you can expose a safe API that is impossible to misuse in a way that leads to undefined behavior. That's the succinct way of putting it anyway. The `memchr` crate, for example, has an entirely safe API. Nobody needs to use `unsafe` to use any part of it. But its internals have `unsafe` littered everywhere. Could the crate have bugs that result in UB due to a particular use o…
"The encapsulation referred to here is that you can expose a safe API that is impossible to misuse in a way that leads to undefined behavior. That's the succinct way of putting it anyway." Well, no, actually. At least, not in an (IMHO) useful way. I can break your safe API by getting the constraints wrong on unsafe code inside that API. Also, unsafe usage elsewhere is not local. I can break your impossible to misuse…
The tooling and the encapsulation go hand in hand.
> The idea that you will convince people not to write broken unsafe code, in ways that breaks safe APIs, or that the ability to assign blame matters, is very strange to me, and is no better than C. As systems grow, the likelihood of totally safe transmutes growing in them is basically 100% :)
To be honest this doesn't track with my experience at all. Unsafe just isn't that commonly used in projects I contribute to. When it is, it is aggressively encapsulated.
Re: Zlib-rs is faster than C
#430Which library compiles faster. Which library has fewer dependencies. Is each library the same size. Which one is smaller.
Using this I can statically compile a cross-compiler. Total size uncompressed 169.4MB.
I use GCC to compille zlib and a wide variety of other software. I can build an operating system from the ground up.
Perhaps someday during my lifetime it will be possible to compile programs written in Rust using inexpensive computers with modest amounts of memory, storage and relatively slow CPUs. Meanwhille, there is C.