Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uninitialized memory: Unsafe Rust is too hard

lucumr.pocoo.org

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Uninitialized memory: Unsafe Rust is too hard

#41

Post by sAbakumoff »

spacechild1 wrote: post #32
ccleve wrote: post #11

Earlier quoted context omitted.

Why was this downvoted? Rust may be the "most loved" language, but after a few weeks with it, I don't love it. We've got to face the reality that it makes simple things way too complicated. In fairness, I have found the compiler errors to be extremely helpful. They often tell me exactly what to fix. But honestly, they shouldn't have to do that. The syntax should have been obvious from the beginning, as it is in most…

I guess because it's off topic. TFA is about a specific Rust issue and a generic comment about "Rust is hard to learn" doesn't add anything to the conversation. It's like the generic "C++ is way to complicated" comment under every C++ post. They just incite language flame wars and district from the actually interesting stuff.

Right, the HN comments are all about being on topic.

Re: Uninitialized memory: Unsafe Rust is too hard

#42

Post by staticassertion »

I think that the premise here is correct - writing unsafe Rust is too hard. There are lots of footguns.

This isn't a very good motivating example but I suppose it does the job of showing the various hoops one has to jump through when using unsafe.

I think right now the approach is to make unsafe "safe" (ie std::mem::uninitialized -> MaybeUninit) at the cost of complex, and eventually to build out improved helpers and abstractions. Obviously this is still ongoing.

But also, just don't write unsafe? It's very easy to avoid.

Re: Uninitialized memory: Unsafe Rust is too hard

#43

Post by dathinab »

andreareina wrote: post #2

I don't know rust, but why isn't the answer, don't try to do what you'd do in C like construct uninitialized structs?

It's the correct answer.

You still sometimes need it like:

- when highly optimizing some algorithms

- doing FFI

So places you find it include some aync runtimes, some algorithm libraries, the standard library.

Still often times you initialize it by fully writing it, not by writing fields.

Anyway rules are simple:

1. use `ptr::write` instead of `ptr =`

2. use `addr_of_mut!(ptr.x)` instead of `&ptr.x` to get field pointers

3. uhm, `packed` structs are a mess, if you have some you need to take a lot of additional care, this is not limited to rust but also true for C/C++

Also you do not need `#[repr(C)]`, while the rust-specification is pending and as such `repr(Rust)` is pretty much undefined you still can expect fields to be aligned (as else you would have unaligned-`&` which is quite a problem and would likely cause a bunch of breakage through the eco-system).

Re: Uninitialized memory: Unsafe Rust is too hard

#44

Post by staticassertion »

xorvoid wrote: post #29
judofyr wrote: post #8

Earlier quoted context omitted.

One of the core ideas behind unsafe blocks is that they don’t actually change any semantics. All they do is allow more operations. This makes it a lot easier to reason about (for both the programmer and the compiler) since there’s not two different set of rules to remember. It does however makes things a bit clunky since the unsafe bits need to ensure a “safe” state throughout the whole block and not only by the end…

I’ve never understood why they don’t just support partially initialized structs. They’re already doing control flow analysis for initializing variables. It seems like a natural extension to do this for aggregate types (product and sum). From a type theory perspective, a struct T is not a T in unitialized state, it’s. “partial T” that at some point gets transformed into a T. So, you’d not be able to use the T in the n…

It's not problematic, it's just not work that's been done yet. Rust isn't finished. I bet you could get an RFC pushed through and implement it if you wanted to, it certainly is a promising idea.

Re: Uninitialized memory: Unsafe Rust is too hard

#45

Post by ______-_-______ »

notpopcorn wrote: post #9

Without any unsafe code this is simply: let role = Role { name: "basic", flag: 1, disabled: false, }; The language tries to prevent you from interacting with a `Role` object that's not fully initialized. `mem::zero()` could work, but then you'll have to turn the `&'static str` into an `Option ` or a raw pointer, to indicate that it might be null. You could also add `#[derive(Default)]` to the struct, to automatically…

Exactly this. I'm not sure what the author's practical goal is with that code. He rejects #[repr(C)] a few times, so it's not FFI.

Yes, working with uninitialized memory is tedious. But that isn't something you ever have to do. If you're translating some C to Rust, write it using Rust idioms, instead of trying to preserve every call to malloc/free and every access to uninitialized memory.

Re: Uninitialized memory: Unsafe Rust is too hard

#46

Post by pjmlp »

jeroenhd wrote: post #27
sidkshatriya wrote: post #10

Earlier quoted context omitted.

> I am under the impression that even _safe_ Rust is really hard to learn. [...] > The syntax seems overcomplicated, the compiler errors are cryptic, the IDE is not helpful. Yes, Rust is hard to learn. Rust does _seem_ over-complicated. However I like to compare Rust to exercise. You need to do a bit of it before you start reaping the benefits of it. If you suspend your judgement for a bit and try to write some Rust,…

I much prefer Rust over C++, but I find that the problems of C++ have little to do with the language itself. I've been watching the videos by Andreas King on SerenityOS and the code is so clean that at first I wondered what programming language I was even looking at. I see the SerenityOS codebase as proof that if C++ programmers wanted to write modern, elegant, readable code, they definitely could. In practice, thoug…

Having acquired C++ into my toolbox in 1993, and thus lived through its adoption over C (which still owns several domains after 50 years), I am bettting that Rust at 30 years of age into production will suffer similar fate.

Re: Uninitialized memory: Unsafe Rust is too hard

#47

Post by staticassertion »

sAbakumoff wrote: post #7

I am under the impression that even _safe_ Rust is really hard to learn. Several years ago I started with GoLang and it was so easy to start programming even advanced things almost instantly..Rust drives me crazy. The syntax seems overcomplicated, the compiler errors are cryptic, the IDE is not helpful.

Rust initially was much harder to learn. The compiler was considerably more strict - rejecting a lot of programs that were entirely valid. That earned rust a very negative "hard language" reputation early on.

That hasn't been the case for years. The 2018 edition officially stabilized Non-Lexical Lifetimes, allowing tons of valid programs to work. There have been a lot of other improvements since then to address papercuts.

At this point Rust is a pretty easy language to learn imo.

Re: Uninitialized memory: Unsafe Rust is too hard

#48

Post by staticassertion »

masonium wrote: post #36
kaashif wrote: post #33

Earlier quoted context omitted.

> A good example of a cryptic rust error is the `expected type Foo, but found type Foo` error message which is very inscrutable, especially to a new users. Does Rust actually give an error like `expected type Foo, but found type Foo`, as in both types are the same in the error? I don't think I've seen that before, but I don't write much Rust. If both types are the same, what does the error mean?

I've seen this error a lot when working with two different versions of the same library. Specifically, you can directly include version A, but a different library depends on a version B, with some of that exposed in the public API.

I think the compiler will now give you a hint that they may be from different versions. If not, next time you see it you should open up a bug in rustc.

To anyone who gets a cryptic error message - that's a bug, report it.

Re: Uninitialized memory: Unsafe Rust is too hard

#49

Post by staticassertion »

spacechild1 wrote: post #32
ccleve wrote: post #11

Earlier quoted context omitted.

Why was this downvoted? Rust may be the "most loved" language, but after a few weeks with it, I don't love it. We've got to face the reality that it makes simple things way too complicated. In fairness, I have found the compiler errors to be extremely helpful. They often tell me exactly what to fix. But honestly, they shouldn't have to do that. The syntax should have been obvious from the beginning, as it is in most…

I guess because it's off topic. TFA is about a specific Rust issue and a generic comment about "Rust is hard to learn" doesn't add anything to the conversation. It's like the generic "C++ is way to complicated" comment under every C++ post. They just incite language flame wars and district from the actually interesting stuff.

It's because, for some reason, the rust community is extremely, overly aggressive about downvoting. I think we can all just admit that - I've been using Rust since 2014 and it's always been an issue and it needs to be called out.

Re: Uninitialized memory: Unsafe Rust is too hard

#50

Post by pjmlp »

jeroenhd wrote: post #25
sAbakumoff wrote: post #22

Earlier quoted context omitted.

That is inspiring. Thanks a lot! Perhaps the problem was that I was overconfident and immediately started with pretty advanced Rust - writing a web assembly that performs big data analysis using the "polars" library.

I consider myself reasonably competent in Rust but the webassembly stuff always trips me up, and so do most cross-language tools. You might've just had an unfortunate experience. I'm not sure if I'd pick Rust for WASM unless you already know it, but I suppose it's a good reason to learn the language. The problem with Rust is that to write good Rust, you need to accept that you can't use the same approach to solve a p…

To be honest, I would even consider C for WASM despite my usual rants, after all with the security sales pitch for Webassembly it shouldn't matter after all.
Post reply on HN