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

81–90 of 127 posts

Re: Uninitialized memory: Unsafe Rust is too hard

#81

Post by jeroenhd »

pjmlp wrote: post #46
jeroenhd wrote: post #27

Earlier quoted context omitted.

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.

Definitely. I think Rust's more restrictive nature will leave it a little better than C and C++, but as technology evolves, every language will eventually show its age.

Re: Uninitialized memory: Unsafe Rust is too hard

#82

Post by jeroenhd »

pjmlp wrote: post #50
jeroenhd wrote: post #25

Earlier quoted context omitted.

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.

Agreed, without the risk of memory corruption and the associated security risks, C can be used without too much hesitation (as long as your complicated pointer code doesn't break your own data structures and mess up your program, of course!).

I think it would be a challenge to compile all dependencies for a fully features C program into WASM, but if you pick your libraries well, C could be an excellent language for speeding up complex calculations in Javascript.

Re: Uninitialized memory: Unsafe Rust is too hard

#83

Post by Subsentient »

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,…

The big issue I had with learning Rust is not the simple stuff -- I could write safe Rust fairly quickly. The problem I continue to have is that many internal behaviors of the language are totally undocumented and inexplicable. For example, implicit reborrows. They happen everywhere, but it's still just a pile of unicorn farts as far as documentation. The idea of a language with no documentation for a given syntax is horrifying. Rust does very well in documentation for beginners, but if you actually want to understand the language, if you want to know what's really happening, you're usually fucked.

Re: Uninitialized memory: Unsafe Rust is too hard

#84

Post by jeroenhd »

sAbakumoff wrote: post #40
jeroenhd wrote: post #25

Earlier quoted context omitted.

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

I can't say I'm too experienced in writing code for WASM, but I have to say I was pleasantly surprised when I experimented with Go.

It has to be said that I have many (mostly subjective) problems with the Go language and the ecosystem, but with the help of GoLand I was productive in minutes. The layer for exchanging arguments between the browser and the "native" code is a bit weird, but once you get passed that, it's easy to get going.

The Rust problem with WASM is more about learning Rust well and picking the right libraries (many of them have dependencies that don't work well in the browser!). Setting up tools like cargo to compile usable WASM files also takes a little practice, but that's at most an afternoon of messing around before you should be reasonably comfortable with it. In my opinion, the main improvements Rust brings to the table are the (memory) security features and the fearless multithreading, but neither of them are of much use within the WASM runtime. The borrow checker will still help you write correct code, but it can be an unnecessary pain in the ass when it doesn't need to be. Rust is a great systems programming language, but I'm not so sure about it becoming the de-facto WASM standard.

Of course, if you already know Rust, or know a library that would be super useful to you, it's great that Rust can Just Work (TM) with the right setup. First-party tooling support is pretty great for a language to have!

If I had to choose, I think I'd pick a language that I'm comfortable with (C#, Kotlin, Java) and has the necessary libraries easily available, and see if the tooling works well for my use cases.

I'm also watching Zig evolve with interest; it's not quite there yet, but it's integration with C libraries and some of its more modern language features are very promising. WASM code doesn't need many of the complexities modern languages bring, but older languages like C can lead to dangerous programming paradigms, so I think a mix between the two can produce clean, performant and fully-featured code. I wouldn't recommend it for production use yet, though, as the language is still in constant development with breaking changes between point releases!

Re: Uninitialized memory: Unsafe Rust is too hard

#85

Post by gpm »

pjmlp wrote: post #74
gpm wrote: post #70

Earlier quoted context omitted.

Needing to use a `Cell` in rust is incredibly rare in my experience. It's very far from clear to me that the increased complexity coming from allowing overriding the meaning of `=`, and worse of `variable_name_that_happens_to_contain_a_certain_type` would be remotely worth it.

Unless GUI code comes up with Rc > all over the place.

RefCell is distinct from Cell, more common, but much worse tradeoffs for implicit access, because accessing it can crash your program.

Re: Uninitialized memory: Unsafe Rust is too hard

#86

Post by DSMan195276 »

ivraatiems wrote: post #80
DSMan195276 wrote: post #67

Earlier quoted context omitted.

> If you want to write unsafe code, I think that's perfectly fine, but Rust is not going to cater to your desires. C and C++ will give you the tools you need with the conveniences you want. This is a bit of a odd suggestion to me, honestly, you're basically saying Rust is not intended to be a C/C++ replacement. There is definitely a reality that not everything can be written in completely safe Rust, and a lot of the…

Calling Rust "a C/C++ replacement" is, I think, slightly underselling what it's supposed to do. As I understand it, the goal of Rust is more "take all these things that were historically hard to do safely and make them easier to do safely" than "replace C/C++ 1 for 1".

Is it actually achieving that goal though if the advice is "use C if you have to do `unsafe` stuff"? That's really my point. IMO the language was always intended to be able to be used in any situation C is used (with maybe a few exceptions), which includes situations where `unsafe` is necessary.

Re: Uninitialized memory: Unsafe Rust is too hard

#87

Post by dathinab »

kaba0 wrote: post #66
dathinab wrote: post #43

Earlier quoted context omitted.

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 po…

There may of course be rare cases where having it uninitialized helps, but I would wager that even than the compiler could optimize it more often than not.

It's not that simple.

Like the unused bu allocated space in a Vec is basically a `[MaybeUninit]`.

Or in async runtimes you often have an unsized type with an future trait object inlined (through unsized types anyway need a bit more love ;=) ).

Or some C FFI patterns.

But yes I would say in pure rust the use cases for `MaybeUninit` are rare, and the cases where you need pointers to fields even rarer.

Though while rare in comparison to the amount of code not needing it, still needed enough to be somewhere used (e.g. in a dependency) in many projects even if ignoring std.

Re: Uninitialized memory: Unsafe Rust is too hard

#88

Post by dathinab »

queuebert wrote: post #72
dathinab wrote: post #37

The scary thing is: Handling uninitialized memory is hard in C++ (and C), too. You just don't notice and accidentally do it slightly wrong (mainly in C++, in C it's harder to mess up).

Exactly this. And also avoiding initializing memory with zeroes or something is often premature optimization. Very few programs are performant enough to notice the difference.

In my experience the most common use case for zero-memset is not optimizations but to reduce fallout if you happen to initialize a field..., like a newly added field.

Re: Uninitialized memory: Unsafe Rust is too hard

#89

Post by smoldesu »

DSMan195276 wrote: post #86
ivraatiems wrote: post #80

Earlier quoted context omitted.

Calling Rust "a C/C++ replacement" is, I think, slightly underselling what it's supposed to do. As I understand it, the goal of Rust is more "take all these things that were historically hard to do safely and make them easier to do safely" than "replace C/C++ 1 for 1".

Is it actually achieving that goal though if the advice is "use C if you have to do `unsafe` stuff"? That's really my point. IMO the language was always intended to be able to be used in any situation C is used (with maybe a few exceptions), which includes situations where `unsafe` is necessary.

For starters, the example I gave (Actix framework) had no such situations where unsafe code was imperative to having it function. That's where the drama originated from there.

Secondly, I don't think the goal of Rust is to rewrite the entire kernel (or replace C/C++ for that matter). Rust is optimized around writing ergonomic, safe code. It's compiler is designed to produce high-performance binaries with minimal UB. Sure, they could designate a team for making the unsafe Rust experience better, but why bother? C++ already does that and does it well. The idea of "oxidation", or slowly replacing safety-critical portions of a program in Rust, doesn't necessitate fully replacing any of the languages that came before it, and while there are situations where unsafe code is undeniably necessary, I don't really think there's much of a reason to replace C or C++ for those uses. Any of the replacements you could write in Rust wouldn't be ergonomic, easy to read or well optimized.

Re: Uninitialized memory: Unsafe Rust is too hard

#90

Post by Ericson2314 »

raphlinus wrote: post #65
Ericson2314 wrote: post #55

The write_unaligned is pure FUD. Regular unpacked structs don't violate alignment on fields!

In the spirit of being charitable, I would say that the article is highlighting a place where the guarantees are incompletely documented. And not having a solid specification and clear documentation is absolutely one of the things that makes unsafe Rust hard. I'd actually like to qualify that a bit. Doing unsafe is not especially hard, just use pointers everywhere instead of references. That's exactly like C (which d…

> In the spirit of being charitable

You are being nice, but even if there is a documentation error, we can prove that if safe rust isn't completely broken, and `& x.field` is allowed in safe Rust, then fields must be aligned. It is just preposterous Rust would be more broken than C in this regard.

> but the syntax is clunkier, you have to use function calls instead of concise operators like * and ->.

Yes I agree, the syntax does suck. I see the macros use an unstable &raw, that would be more concise.

I think would be really good is if x->y in Rust matched &x->y in C. That is nicely orthogonal to dereferencing, and always safe.

Post reply on HN