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

Pitfalls of Safe Rust

corrode.dev

Post reply on HN
Print view View original

61–70 of 145 posts

Re: Pitfalls of Safe Rust

#61

Post by apatheticonion »

sgt wrote: post #8

Golang might be better for writing robust software, if that is the goal. Robust services that don't go down.

Both have their place but after writing both extensively, I much prefer Rust - despite the pitfalls.

My biggest critisim of Rust (in comparison to Go) is the lack of a powerful standard library while Go's standard library is outstanding. I would also like to see standardized interfaces in Rust (like AsyncWrite) and in general the async story could be better - though I appreciate the versatility.

Re: Pitfalls of Safe Rust

#62

Post by whytevuhuni »

pkhuong wrote: post #56
dymk wrote: post #33

Earlier quoted context omitted.

That subculture is called “people who haven’t read the docs”, and I don’t see why anyone would give a whole lot of weight to their opinion on what technical terms mean

Someone tell that to the standard library. No memory safety involved in non-zero numbers https://doc.rust-lang.org/std/num/struct.NonZero.html#tymeth...

There is, since the zero is used as a niche value optimisation for enums, so that Option> occupies the same amount of memory as u32.

But this can be used with other enums too, and in those cases, having a zero NonZero would essentially transmute the enum into an unexpected variant, which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant.

Re: Pitfalls of Safe Rust

#63

Post by Aurornis »

pjmlp wrote: post #22
whytevuhuni wrote: post #9

Earlier quoted context omitted.

No, the Rust community almost universally understands "safe" as referring to memory safety, as per Rust's documentation, and especially the unsafe book, aka Rustonomicon [1]. In that regard, Safe Rust is safe, Unsafe Rust is unsafe, and C++ is also unsafe. I don't think anyone is saying "C++ is all unsafe." You might be talking about "correct", and that's true, Rust generally favors correctness more than most other l…

Mostly, there is a sub culture that promotes to taint everything as unsafe that could be used incorrectly, instead of memory safety related operations.

I see this subculture far more in online forums than with fellow Rust developers.

Most often, the comments come from people who don’t even write much Rust. They either know just enough to be dangerous or they write other languages and feel like it’s a “gotcha” they can use against Rust.

Re: Pitfalls of Safe Rust

#64

Post by zozbot234 »

whytevuhuni wrote: post #62
pkhuong wrote: post #56

Earlier quoted context omitted.

Someone tell that to the standard library. No memory safety involved in non-zero numbers https://doc.rust-lang.org/std/num/struct.NonZero.html#tymeth...

There is, since the zero is used as a niche value optimisation for enums, so that Option > occupies the same amount of memory as u32. But this can be used with other enums too, and in those cases, having a zero NonZero would essentially transmute the enum into an unexpected variant, which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant.

> which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant

By that standard anything and everything might be tainted as "unsafe", which is precisely GP's point. Whether the unsafety should be blamed on the outside code that's allowed to create a 0-valued NonZero or on the code that requires this purported invariant in the first place is ultimately a matter of judgment, that people may freely disagree about.

Re: Pitfalls of Safe Rust

#65

Post by glandium »

Sharlin wrote: post #38

> Surprising Behavior of Path::join With Absolute Paths > I was not the only one who was confused by this behavior. Here’s a thread on the topic, which also includes an answer by Johannes Dahlström: > > The behavior is useful because a caller […] can choose whether it wants to use a relative or absolute path, and the callee can then simply absolutize it by adding its own prefix and the absolute path is unaffected whi…

It's the same in at least Python, so it's not a Rust idiosyncratic behavior. The "absolutize" method you're asking for exists since 1.79. https://doc.rust-lang.org/stable/std/path/fn.absolute.html

Re: Pitfalls of Safe Rust

#66

Post by bogeholm »

conradludgate wrote: post #51
forrestthewoods wrote: post #27

> Overflow errors can happen pretty easily No they can’t. Overflows aren’t a real problem. Do not add checked_mul to all your maths. Thankfully Rust changed overflow behavior from “undefined” to “well defined twos-complement”.

Overflow errors absolutely do happen. They're just no longer UB. It doesn't make them non-errors though. If your bank account balance overflowed, you'd be pretty upset.

On the other hand, there’s a solid use case for underflow.

Re: Pitfalls of Safe Rust

#67

Post by zozbot234 »

bigstrat2003 wrote: post #53
woah wrote: post #2

Is "as" an uneccesary footgun?

I wouldn't say so. I quite like "as". It can have sharp edges but I think the language would be significantly worse off without it.

The question is not whether the language should include such a facility, but whether 'as' should be the syntax for it. 'as' is better than the auto conversions of C but it's still extremely obscure. It would be better to have some kind of explicit operator marking this kind of possibly unintended modulo conversion. Rust will gain safe transmute operations in the near future so that will perhaps be a chance to revise this whole area as well.

Re: Pitfalls of Safe Rust

#68

Post by kelnos »

conaclos wrote: post #59

I find it strange that the article doesn't talk about the alternative to checked arithmetic: explicit Wrapping [0] and Saturating [1] types, also provided as methods on numeric types (e.g. `usize::MAX.saturating_add(1)`). Regarding `as` casting, I completely agree. I am trying to use safe `From::from` instead. However, this is a bit noisy: `usize::from(n)` vs `n as usize`. [0] https://doc.rust-lang.org/std/num/struct…

> I am trying to use safe `From::from` instead. However, this is a bit noisy: `usize::from(n)` vs `n as usize`.

If there's enough information in the surrounding code for type inference to do its thing, you can shorten it to `n.into()`.

Re: Pitfalls of Safe Rust

#69

Post by int_19h »

phoenk wrote: post #46
ampere22 wrote: post #43

Earlier quoted context omitted.

If a C++ developer decides to use purely containers and smart pointers when starting a new project, how are they going to develop unsafe code? Containers like std::vector and smart pointers like std::unique_ptr seem to offer all of the same statically checked guarantees that Rust does. I just do not see how Rust is a superior language compared to modern C++

The commonly given response to this question is two-fold, and both parts have a similar root cause: smart pointers and "safety" being bolted-on features developed decades after the fact. The first part is the standard library itself. You can put your data in a vec for instance, but if you want to iterate, the standard library gives you back a regular pointer that can be dereferenced unchecked, and is intended to be i…

The standard library doesn't give you a regular pointer, though (unless you specifically ask for that). It gives you an iterator, which is pointer-like, but exists precisely so that other behaviors can be layered. There's no reason why such an iterator can't do bounds checking etc, and, indeed, in most C++ implementations around, iterators do make such checks in debug builds.

The problem, rather, is that there's no implementation of checked iterators that's fast enough for release build. That's largely a culture issue in C++ land; it could totally be done.

Re: Pitfalls of Safe Rust

#70

Post by wongarsu »

adgjlsfhk1 wrote: post #41
whytevuhuni wrote: post #5

Earlier quoted context omitted.

That was my first impression as well. So much of Rust’s language and standard library enforces correctness, that gaps start to feel way more visible. “as” is a good example. Floats are pretty much the only reason PartialEq exists, so why can’t we have a guaranteed-not-NaN-nor-inf type in std and use that everywhere? Why not make wrapping integers a panic even in release mode? Why not have proper dependent types (e.g.…

The other option would be to change how floating point works. IEEE specifies operations, not names, so it would be totally valid to have <= on floats be a total order (using integer cpu instructions), and make a function called IEEEAreIdiotsWhoThinkThisIsFloatingPointLessThan which is the partial order that sucks.

For purposes of sorting, Rust does offer a non-IEEE order as f64::total_cmp. You can easily build a wrapper type that uses that for all comparisons, or use a crate that does it for you

https://doc.rust-lang.org/std/primitive.f64.html#method.tota...

Post reply on HN