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

21–30 of 145 posts

Re: Pitfalls of Safe Rust

#21

Post by hu3 »

NoTeslaThrow wrote: post #14
burakemir wrote: post #6

Earlier quoted context omitted.

It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…

If english had static checks this kind of runtime pedantry would be unnecessary. Sometimes it's nice to devote part of your brain to productivity rather than checking coherence.

[flagged]

Re: Pitfalls of Safe Rust

#22

Post by pjmlp »

whytevuhuni wrote: post #9
burakemir wrote: post #6

Earlier quoted context omitted.

It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…

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.

Re: Pitfalls of Safe Rust

#23

Post by pjmlp »

sgt wrote: post #8

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

First they have to improve the memory model due to possible races when sharing slices due to their fat pointers implementation.

Re: Pitfalls of Safe Rust

#24

Post by hansvm »

quotemstr wrote: post #7

Some of this advice is wrongheaded. Consider array indexing: usually, an out of bounds access indicates a logic error and should fail fast to abort the problem so it doesn't go further off the rails. Encouraging people to use try-things everywhere just encourage them to paper over logic bugs and leads to less reliable software in the end. Every generation has to learn this lesson anew through pain.

Try-things have the benefit of accurately representing the thing you're describing. Leave it to the caller to decide whether to panic or resize the data structure or whatever.

That's also not the only choice in the design space for correct array accesses. Instead of indices being raw integers, you can use tagged types (in Rust, probably using lifetimes as the mechanism if you had to piggy back on existing features, but that's an implementation detail) and generate safe, tagged indices which allow safe access without having to bounds check on access.

However you do it, the point is to not lie about what you're actually doing and invoke a panic-handler-something as a cludgy way of working around the language.

Re: Pitfalls of Safe Rust

#25

Post by surajrmal »

quotemstr wrote: post #10
burakemir wrote: post #6

Earlier quoted context omitted.

It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…

Safe Rust code doesn't have accidental remote code execution. C++ often does. C++ people need to stop pretending that "safety" is some nebulous and ill-defined thing. Everyone, even C++ people, shows perfectly damn well what it means. C++ people are just miffed that Rust built it while they slept.

Accidental remote code execution isn't limited to just memory safety bugs. I'm a huge rust fan but it's not good to oversell things. It's okay to be humble.

Re: Pitfalls of Safe Rust

#26

Post by pjmlp »

bombela wrote: post #15
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.…

I have been following rust very closely since 2013. As Rust is both evolving and spreading wide, we; the programmers, users of Rust; are also leveling up in how we approach correctness and design with it. Maybe the next evolution will be something like Haskell but fast like Rust is fast like C without the pain of C++. But it takes a while for the world to catch up, and for everybody to explore and find ways to work w…

There is hardly any evolution from pointer to malloc, C is one of the few systems languages, including those that predated it, where one needs math to allocate heap memory.

I do agree that the evolution is most likely a language that combines automatic resource management with affine/linear/effects/dependent/proofs.

Or AIs improve to the point to render all existing programming languages a thing from the past, replaced by regular natural languages and regular math.

Re: Pitfalls of Safe Rust

#27

Post by forrestthewoods »

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

Re: Pitfalls of Safe Rust

#28

Post by brundolf »

whytevuhuni wrote: post #9
burakemir wrote: post #6

Earlier quoted context omitted.

It is consistent with the way the Rust community uses "safe": as "passes static checks and thus protects from many runtime errors." This regularly drives C++ programmers mad: the statement "C++ is all unsafe" is taken as some kind of hyperbole, attack or dogma, while the intent may well be to factually point out the lack of statically checked guarantees. It is subtle but not inconsistent that strong static checks ("s…

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…

Formally the team/docs are very clear, but I think many users of Rust miss that nuance and lump memory safety together with all the other features that create the "if it compiles it probably works" experience

So I agree with the above comment that the title could be better, but I also understand why the author gave it this title

Re: Pitfalls of Safe Rust

#29

Post by neillyons »

sgt wrote: post #8

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

Golang will panic with a runtime error index out of range if you index out of bounds. There doesn't seem to be a nice built in way to do `arr.get(3)` like in Rust.

    slice := []int{1, 2, 3}
    i := slice[3]
    fmt.Println(i)

Re: Pitfalls of Safe Rust

#30

Post by IshKebab »

sgt wrote: post #8

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

I don't think so. Rust has much stronger typing than Go which allows you to prevent more classes of bugs than just memory errors.

The coolest one I've heard is that Fuchsia's network stack managed to eliminate deadlocks.

But even on a basic level Rust has that "if it compiles it works" experience which Go definitely doesn't.

Post reply on HN