Live data from Hacker News

What it feels like when Rust saves your bacon

smallcultfollowing.com

91–100 of 192 posts

Re: What it feels like when Rust saves your bacon

#91
post #31

Earlier quoted context omitted.

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

I work in probably what is considered one of the least "safe" languages: C++ The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic". From recent time I can recall only one that was a programming mistake and not architecture/business logic related. It was a missing break in a switch that already had some fall…

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or sigils and so on, but I also observe that:

1. High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught.

2. I see sometimes C++ instructors making the same claims you do and then spending half of a lesson tracking down a memory mistake, (Casey Muratori) or in the same month a tweet from a game engine developer saying they don't really see the value of garbage collection and then tweeting about how they spent 48 hours tracking down a memory mistake. (of course, for a game engine that is what you have to do sometimes!)

There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc.

Re: What it feels like when Rust saves your bacon

#92

Earlier quoted context omitted.

Maybe I'm wrong, but I believe that most of the architecting that you describe would be effectively what you do with regards to performance as well: Minimizing change of ownership, moving to a system with more static allocations with fewer "objects" that are linked into a variety of subsystems.

Yes, that's true. In a sense, c++ requires good code structuring. That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture. That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism. Extending lifetimes by pooling or similar is also quite common,…

> Creating trees or graphs can be cumbersome

Wouldn't Rust have the same problem with this (if not worse)?

Re: What it feels like when Rust saves your bacon

#93

Earlier quoted context omitted.

Maybe I'm wrong, but I believe that most of the architecting that you describe would be effectively what you do with regards to performance as well: Minimizing change of ownership, moving to a system with more static allocations with fewer "objects" that are linked into a variety of subsystems.

Yes, that's true. In a sense, c++ requires good code structuring. That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture. That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism. Extending lifetimes by pooling or similar is also quite common,…

> and IMO it's very biased towards virtual methods to solve polymorphism.

Is it? These days I'd expect C++ to be very biased towards using templates for polymorphism. After all, templates are a thing that C++ provides with functionality that other languages often lack, whereas in the field of virtual methods/"dynamic dispatch OOP" C++ severely lags behind other languages. Choosing between two features of a language and using exactly the one that is worse in comparison to your competition feels wrong to me.

Re: What it feels like when Rust saves your bacon

#94
post #31

Earlier quoted context omitted.

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

I work in probably what is considered one of the least "safe" languages: C++ The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic". From recent time I can recall only one that was a programming mistake and not architecture/business logic related. It was a missing break in a switch that already had some fall…

>The issues that Rust is supposed to help with are simply not what we spent time on.

There could be plenty of bugs in your codebase but just because you don't spend time on them doesn't mean they don't exist. Hundreds of millions of people used OpenSSL everyday for 2 years after the Heartbleed bug was introduced. It didn't cause any obviously broken code until someone exploited it to read credit card numbers off of a remote server.

Re: What it feels like when Rust saves your bacon

#95
post #31

Earlier quoted context omitted.

I work in probably what is considered one of the least "safe" languages: C++ The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic". From recent time I can recall only one that was a programming mistake and not architecture/business logic related. It was a missing break in a switch that already had some fall…

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or sigils and so on, but I also observe that: 1. High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. 2. I see sometimes C++ instructors making the same claims you do and th…

I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself.

The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

Re: What it feels like when Rust saves your bacon

#96
post #92

Earlier quoted context omitted.

Yes, that's true. In a sense, c++ requires good code structuring. That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture. That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism. Extending lifetimes by pooling or similar is also quite common,…

> Creating trees or graphs can be cumbersome Wouldn't Rust have the same problem with this (if not worse)?

I was told that deferred_ptr/deferred_heap was supposed to solve these things for C++, so perhaps that would make Rust the option with worse problems in this department. Not sure where it got by now, though.

Re: What it feels like when Rust saves your bacon

#97
post #56

Rust is undoubtedly a step forward in correctness, but boy, the article's code is so thick that for me, that I am a C++ programmer, is almost unreadable, especially for a quick reading... I skipped all the code and only read the text. I got to the point where it mentions that the language prevented them from storing a pointer to a stack object in a heap object, and that's really great, but boy oh boy, the code presen…

> It seems to me that the more sophisticated the safety a language provides is the more complex its error messages/code are. It would be so nice if we could solve both problems at the same time...

That is incredibly hard, yes. But at least if you are ok with the overhead of GC or RC then this is a solved problem - the bug in question here wouldn't happen in Go/Swift/C#/Java/JavaScript/Python/Ruby/etc. And that is most software today.

(But when you need maximal performance and maximal safety then Rust is an incredible option!)

Re: What it feels like when Rust saves your bacon

#98
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…

>I went through about 3 years of tickets (limited to only the bugs reported)

This statement is meaningless without any insight on how bugs were created. If the bug reports exclusively dealt with "happy-path" or "business logic QA", then of course you won't see any CVEs. Did the use of fuzzers or address sanitizers create bug reports? Were these tools even used? If not, the claim that only one of 1000 bugs were memory safety issues isn't credible; you weren't looking for them so of course you didn't find them.

I think it says a lot when almost every C++ developer claims to have a higher quality code base compared to say Linux or Chromium when it comes to memory safety errors.

Re: What it feels like when Rust saves your bacon

#99

Earlier quoted context omitted.

Have you seen modern C++? It has had new syntax bolted on every couple years for the past few decades, the result is quite phenomenal.

Can you name what new syntax you abhor? I mean, other than [] (){}() being a valid C++ expression [0], C++ hasn't even made any notable sygil-related syntax changes recently. Sure, some keywords were added (auto, constexpr, co_yield...) but I don't see how that leads to "ugly" syntax. [0]: That's a lambda capturing no state, having no template parameters, taking no arguments, with an empty body, finally being called…

Anything with templates, type traits, especially when nested. (The kind of spew you get on an compilation error). Even

  template
  struct foo() )>>
       : std::true_type { };
looks terrible and that's just basic.

Re: What it feels like when Rust saves your bacon

#100
post #95

Earlier quoted context omitted.

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or sigils and so on, but I also observe that: 1. High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. 2. I see sometimes C++ instructors making the same claims you do and th…

I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself. The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

I'm sure there is a ton of variance. I have done some Rust projects where I run into absolutely no safety complaints from Rust because it just isn't the kind of code that does anything the borrow checker cares about. For those development time ends up typically faster than C/C++ due to various syntax and tooling niceties.

Other projects will really get into domains where you have to work hard to satisfy the borrow checker and it can slow you down a lot. In a real application you won't be writing lockless thread queues for a big % of the time. But then for a real application the compile times will start to weigh on you more. (Though, C++ does not always compile fast either unless some care is taken to be sure it does)

Post reply on HN