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

What it feels like when Rust saves your bacon

smallcultfollowing.com

Post reply on HN
Print view View original

21–30 of 192 posts

Re: What it feels like when Rust saves your bacon

#21

Post by lelanthran »

atoav wrote: post #13
shuger wrote: post #8

This article is super overcomplicated. All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope. Context provided adds nothing. I must say - as someone who doesn't use rust - I haven't had this type of issue in years, and when I did it wasn't hard to debug. You get corrupted data, set data breakpoint and in the provided example you will see it being modified by…

It all depends on the complexity of your application. The type of guarantees Rust offers in my experience becomes exponentially more useful as your application grows in size.

> It all depends on the complexity of your application. The type of guarantees Rust offers in my experience becomes exponentially more useful as your application grows in size.

Sure, but the development pattern that get used for larger applications typically don't benefit from Rust's additional safety; for one you're going to be using a garbage collected language.

Re: What it feels like when Rust saves your bacon

#22

Post by bestouff »

shuger wrote: post #8

This article is super overcomplicated. All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope. Context provided adds nothing. I must say - as someone who doesn't use rust - I haven't had this type of issue in years, and when I did it wasn't hard to debug. You get corrupted data, set data breakpoint and in the provided example you will see it being modified by…

Yeah no. In my experience, when several people commit to a common C/C++ codebase this kind of issue become really exhausting when it happens more than once, and the symptoms may be so subtle it's a bitch to debug.

Rust lowers your mental load. You spend more time being creative and way less time debugging "obvious" (or not) mechanical problems (reference not-on-stack-anymore variables, use-after-free, concurrent write access and all kind of compiler undefined behavior). That why garbage collected languages are so successful (they let you concentrate on the business logic) and for the first time it's available in a system language.

Everything that can be done by your computer should be done by your computer. You should leave your precious brain cells available for the important stuff.

Re: What it feels like when Rust saves your bacon

#24

Post by rob74 »

kjksf wrote: post #18
proto_lambda wrote: post #5

Earlier quoted context omitted.

You mean the tale of someone rewriting a very complex and fiddly software from scratch, having it work great in production, and then using the ecosystem's great tooling to easily find and eliminate even more bugs than what the language already protected them from?

The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…

What you said, although I would have probably phrased it less harshly :)

But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.

Re: What it feels like when Rust saves your bacon

#25

Post by vgel »

lelanthran wrote: post #20
shuger wrote: post #8

This article is super overcomplicated. All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope. Context provided adds nothing. I must say - as someone who doesn't use rust - I haven't had this type of issue in years, and when I did it wasn't hard to debug. You get corrupted data, set data breakpoint and in the provided example you will see it being modified by…

Agree; this is not an issue that slows down my development or bughunts. You can get a long way towards safety without learning Rust. It's those rare cases that will get you. It's a trade-off; take the time to learn the language and deliver later, or just use what you already have to deliver a product now.[1] [1] During a Rust discussion some years back, when I was at a different company, on a specialised and large-is…

It probably depends on project type and how complex your ownership models are, but that doesn't really track with large projects having a majority of their CVEs be memory safety issues that are far less likely in Rust[1] (e.g., https://www.chromium.org/Home/chromium-security/memory-safet...)

[1] I say far less likely because obviously it's possible with unsafe Rust, but I've never had one happen, seen one happen in real code, or been affected by part of a dependency tree having one.

Re: What it feels like when Rust saves your bacon

#26

Post by MaulingMonkey »

atoav wrote: post #13
shuger wrote: post #8

This article is super overcomplicated. All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope. Context provided adds nothing. I must say - as someone who doesn't use rust - I haven't had this type of issue in years, and when I did it wasn't hard to debug. You get corrupted data, set data breakpoint and in the provided example you will see it being modified by…

It all depends on the complexity of your application. The type of guarantees Rust offers in my experience becomes exponentially more useful as your application grows in size.

This indeed. Small local console app running on trusted data? Maybe an hour to track down some memory corruption if you're particularly unlucky, in which case shuger's kind of got a point: who cares?

Large network-exposed app? Individual memory corruption heisenbugs have taken me weeks to track down (and weeks before that for QA to create a reliable repro for) - a needle in a huge haystack. They often predate my employment - having lurked semi-silently for who knows how long causing who knows how many unreported crashes. When release dates slip because of bug backlogs filled with memory safety related crash bugs, when ~70% of many vendor CVE reports are down to memory safety issues [1][2][3], and when you personally have to deal with the fallout of all that: shuger's point completely and utterly evaporates.

[1] https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

[2] https://www.chromium.org/Home/chromium-security/memory-safet...

[3] https://langui.sh/2019/07/23/apple-memory-safety/

Re: What it feels like when Rust saves your bacon

#27

Post by imron »

kjksf wrote: post #18
proto_lambda wrote: post #5

Earlier quoted context omitted.

You mean the tale of someone rewriting a very complex and fiddly software from scratch, having it work great in production, and then using the ecosystem's great tooling to easily find and eliminate even more bugs than what the language already protected them from?

The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…

> The thing they rewrote also worked great in production.

It may well have, but the Rust version “was faster, it crashed less, and we even knew it fixed some issues”

https://hacks.mozilla.org/2022/06/everything-is-broken-shipp...

Re: What it feels like when Rust saves your bacon

#28

Post by rob74 »

hnarn wrote: post #7
rob74 wrote: post #3

Yes... but before you start feeling too sure about Rust protecting you from creating bugs, also consider this more cautionary (and very entertaining) tale posted on HN today: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-...

> I needed a bit of palette cleanser This is a fun mistake. It’s “Palate cleanser”.

Works with palette (as in painter's palette) too - start with a clean slate, use a whole different set of colors etc.

Re: What it feels like when Rust saves your bacon

#30

Post by MaulingMonkey »

lelanthran wrote: post #21
atoav wrote: post #13

Earlier quoted context omitted.

It all depends on the complexity of your application. The type of guarantees Rust offers in my experience becomes exponentially more useful as your application grows in size.

> It all depends on the complexity of your application. The type of guarantees Rust offers in my experience becomes exponentially more useful as your application grows in size. Sure, but the development pattern that get used for larger applications typically don't benefit from Rust's additional safety; for one you're going to be using a garbage collected language.

> for one you're going to be using a garbage collected language.

I wish it were true, but promise you it is not. As a counterpoint, I point to most "AAA" gamedev and OS development.

In gamedev it's even a bit flipped: The smaller indie gamedevs can pay the GC hit for Unity's C#, web JS, actionscript flash back in the day, etc. - not much working data, not much garbage. Larger scale titles start missing vsync and having horrible stuttering when GCs are thrown into the mix too brazenly - they're still used on smaller scales (embedding browser tech for UI, limited scope scripting, etc.) but they have a lot of native, non-GCed code.

Post reply on HN