31–40 of 145 posts
> 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”.
Having done a bunch of formal verification I can say that overflows are probably the most common type of bug by far.
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.
Is there a write up on this? That's very cool
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
> The coolest one I've heard is that Fuchsia's network stack managed to eliminate deadlocks. Is there a write up on this? That's very cool
That way you can never lock lock B if you have not received a guard aka lock from lock A prior. Ensured on the type level.
I suppose doing this at scale is a real challenge.
Earlier quoted context omitted.
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.
> The coolest one I've heard is that Fuchsia's network stack managed to eliminate deadlocks. Is there a write up on this? That's very cool
There are some crates which implement lock ordering as well (e.g., [2, 3]). lock-ordering states it's inspired by the technique discussed in the talk as well, for what it's worth.
[0]: https://youtu.be/qd3x5MCUrhw?t=1001 (~16:41 in case the timestamp link doesn't work)
[1]: https://joshlf.com/files/talks/Safety%20in%20an%20Unsafe%20W... (deadlock prevention example starting slide 50)
> 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 which is probably what the caller wanted. The callee doesn’t have to separately check whether the path is absolute or not.
> And yet, I still think it’s a footgun. It’s easy to overlook this behavior when you use user-provided paths. Perhaps join should return a Result instead? In any case, be aware of this behavior.
Oh, hey, that's me! I agree that it's a footgun, for what it's worth, and there should probably get a dedicated "absolutize" method for getting the "prefix this if relative, leave as is if already absolute" semantics.
(link to the thread: https://users.rust-lang.org/t/rationale-behind-replacing-pat...)
Earlier quoted context omitted.
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.
RCEs are almost exclusively due to buffer overruns, sure there are examples where that’s not the case but it’s not really an exaggeration or hyperbole when you’re comparing it to C/C++
Notably the log4shell[1] vulnerability wasn't due to buffer overruns, and happened in a memory safe language.
Earlier quoted context omitted.
Mostly, there is a sub culture that promotes to taint everything as unsafe that could be used incorrectly, instead of memory safety related operations.
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