171–180 of 492 posts
Earlier quoted context omitted.
I heard that aliasing in C prevents the compiler from optimizing aggressively. I can believe Rust's compiler can optimize more aggressively if there's no aliasing problem.
C has the restrict type qualifier to express non-aliasing, hence it shouldn’t be a fundamental impediment.
This is an interesting word. I wonder why no one has written high performance library code in assembly yet at this point?
Earlier quoted context omitted.
Rust's many memory safety features (including the borrow checker) are still enabled in unsafe Rust blocks. For more information: https://news.ycombinator.com/item?id=43382176
But again, not exploited by the code in question . This isn't using the Rust runtime heap, it's doing its own thing with raw pointers/indexing, and even seems to have its own allocator.
Rust does not have a specific "Rust runtime heap."
Earlier quoted context omitted.
Using unsafe blocks in Rust is confusing when you first see it. The idea is that you have to opt-out of compiler safety guarantees for specific sections of code, but they’re clearly marked by the unsafe block. In good practice it’s used judiciously in a codebase where it makes sense. Those sections receive extra attention and analysis by the developers. Of course you can find sloppy codebases where people reach for u…
Isn't it the case that once you use unsafe even a single time, you lose all of Rust's nice guarantees? As far as I'm aware, inside the unsafe block you can do whatever you want which means all of the nice memory-safety properties of the language go away. It's like letting a wet dog (who'd just been swimming in a nearby swamp) run loose inside your hermetically sealed cleanroom.
This isn't a wet dog in a cleanroom. This is cleanroom complex that has a very small outhouse that is labeled as dangerous.
Earlier quoted context omitted.
They're just fundamentally different languages. There's semantics that exist in all four of these quadrants: * defined in C, undefined in Rust * undefined in C, undefined in Rust * defined in Rust, undefined in C * defined in Rust, defined in C
That doesn't seem responsive. The question wasn't whether Rust and C are literally the same language ("duh", as it were), it was effectively "are there meaningful safety features provided to the unsafe zlib-rs code in question in that aren't already available in C toolchains/ecosystems?" And there really aren't. The abbreviated/limited safety environment being exploited by this non-idiomatic Rust code seems to me to…
Ah, so that was like, not in your comment, but in a parent.
> And there really aren't.
I mean, not all of the code is unsafe. From a cursory glance, there's surely way more here than I see in most Rust packages, but that doesn't mean that you get no advantages. I picked a random file, and chose some random code out of it, and see this:
pub fn copy(
dest: &mut MaybeUninit>,
source: &mut DeflateStream,
) -> ReturnCode {
// SAFETY: source and dest are both mutable references, so guaranteed not to overlap.
// dest being a reference to maybe uninitialized memory makes a copy of 1 DeflateStream valid.
unsafe {
core::ptr::copy_nonoverlapping(source, dest.as_mut_ptr(), 1);
}
You mean the implementation is faster than the one in C. Because nothing is “faster than C”.
Earlier quoted context omitted.
C has the restrict type qualifier to express non-aliasing, hence it shouldn’t be a fundamental impediment.
Which is so underused that the whole compiler feature was buggy as hell, and was only recently fixed because compiling Rust where it is the norm exposed it.
Earlier quoted context omitted.
> they've been sitting in nightly unstable for years So many very useful features of Rust and its core library spend years in "nightly" because the maintainers of those features don't have the discipline to see them through.
Before I started working with Rust, I spent a lot of time using Swift for systems-y/server-side code, outside of the Apple ecosystem. There is a lot I like about that language, but one of the biggest factors that drove me away was just how fast the Apple team was to add more and more compiler-magic features without considering whether they were really the best possible design. (One example: adding compiler-magic deri…
Sounds like the Rust's async story.
Earlier quoted context omitted.
> basically written in C Unsafe Rust still has to conform to many of Rust’s rules. It is meaningfully different than C.
It has also way less tooling available than C to analyze its safety.
An optimized version that controls allocations, has good memory access patterns, uses SIMD and uses multi-threading can easily be 100x faster or more. Better memory access alone can speed a program up 20x or more.
Earlier quoted context omitted.
Before I started working with Rust, I spent a lot of time using Swift for systems-y/server-side code, outside of the Apple ecosystem. There is a lot I like about that language, but one of the biggest factors that drove me away was just how fast the Apple team was to add more and more compiler-magic features without considering whether they were really the best possible design. (One example: adding compiler-magic deri…
> the response from leadership was "yes, something like that would be better in the long run, but we want to ship this now." Sounds like the Rust's async story.