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

31–40 of 127 posts

Re: Uninitialized memory: Unsafe Rust is too hard

#31

Post by xorvoid »

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…

As an example, in C the following is quite common:

Data dat;

dat.a = 1;

dat.b = “foobar”;

do_thing(&dat);

I seems like the compiler should be able to treat “dat” as an “maybe uninit” type until after “dat.b” gets assigned.

Re: Uninitialized memory: Unsafe Rust is too hard

#32

Post by spacechild1 »

ccleve wrote: post #11
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.

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.

Re: Uninitialized memory: Unsafe Rust is too hard

#33

Post by kaashif »

eminence32 wrote: post #14
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.

I suspect you might start to receive a bunch of replies from people with the opposite experience (replies from people who find the syntax easy to read, and the compiler errors clear and understandable). I would like to attempt to preempt that by noting that it's totally reasonable for two people to feel drastically different things about a programming language. Neither view is more correct than the other. That said,…

> 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?

Re: Uninitialized memory: Unsafe Rust is too hard

#34

Post by comex »

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…

Rust already supports partially deinitialized structs - that is, moving out of a struct field by field - and there’s no fundamental reason it can’t support partial initialization too.

Indeed, there’s an open issue for it:

https://github.com/rust-lang/rust/issues/54987

But there are a lot of desired features with open issues, so don’t expect this to be implemented anytime soon unless someone takes an interest in it.

Re: Uninitialized memory: Unsafe Rust is too hard

#35

Post by ATsch »

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…

A much better way to do partial initialization is by splitting up the struct into multiple parts. This can be easily done in safe rust with Option, or MaybeUninit if you're really desperate for performance.

Re: Uninitialized memory: Unsafe Rust is too hard

#36

Post by masonium »

kaashif wrote: post #33
eminence32 wrote: post #14

Earlier quoted context omitted.

I suspect you might start to receive a bunch of replies from people with the opposite experience (replies from people who find the syntax easy to read, and the compiler errors clear and understandable). I would like to attempt to preempt that by noting that it's totally reasonable for two people to feel drastically different things about a programming language. Neither view is more correct than the other. That said,…

> 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.

Re: Uninitialized memory: Unsafe Rust is too hard

#38

Post by kaashif »

bitwize wrote: post #24
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…

Prior exposure to C appears to be negatively correlated with ease in learning Rust. This is why I say Rust is not a language for C programmers -- it's for their replacements. Young programmers with only a few years' experience in JavaScript or Ruby are now coding circles around the old C wizards, contributing bare-metal, bit-banging code that is guaranteed to be free of several classes of bugs those C wizards are sti…

That's surprising. I would've thought most C programmers have at least some experience writing C++, and C++ programmers (and C programmers too, but I don't know anyone who programs primarily in C so I can't comment) already do many of the things Rust does for you. Like thinking about lifetimes, const by default, moving instead of copying, avoiding raw pointers like the plague, etc.

Someone who has never thought about that stuff must surely find it harder to appreciate Rust.

Re: Uninitialized memory: Unsafe Rust is too hard

#39

Post by dathinab »

Lvl999Noob wrote: post #26
wyldfire wrote: post #18

Earlier quoted context omitted.

But an idiom from C which might inspire some unsafe rust is to memset a struct to zero after declaration in order to guarantee that all fields are initialized before anything would access them.

Is initializing a NonZero field to 0 really initializing it?

no not at all

IMHO requiring all types in C to have a valid "all zero" variant so that this pattern can be used isn't grate either, somewhat of an anti-pattern even. But an anti-pattern needed for ergonomic C.

The post is a good example for trying to program "like in a different language" just because some tools somewhat allow it. Like in this case "programming rust like it's C".

And if you do rust FFI and have a lot of C experience it is tempting.

Re: Uninitialized memory: Unsafe Rust is too hard

#40

Post by sAbakumoff »

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…

>> I'm not sure if I'd pick Rust for WASM

What would be an alternative if I plan to develop a high-performant data analysis tool for WASM(similar to Perspective[0])? I looked at the list of supported languages[1] and Rust seems to be a good choice.

[0] - https://github.com/finos/perspective

[1] - https://github.com/appcypher/awesome-wasm-langs

Post reply on HN