[shuger]

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 unrelated operations on stack. From there there is only one conclusion. Authors reactions seems to be a bit exaggerated.

[bestouff]

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.

[shuger]

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 fallthroughs so it didn't look incorrect at a glance.

I do understand what Rust is supposed to provide but in practice it's simply an extremely minor source of bugs.

[jackmott42]

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.

[jandrewrogers]

> High quality teams like the Linux kernel team and PostgreSQL

Neither of those code bases are C++, which significantly dilutes your point. A major benefit of modern C++ is that it is much safer than the language Linux and PostgreSQL are written in.

[Daishiman]

Chromium _is_ written in C++, has some of the best coders and one of the best-tested codebases in the world. They're still finding zero-days based on exploits due to the language's failings.

There's a reason Mozilla has decided that all parser code should be moved to Rust ASAP.

[melissalobos]

> High quality teams like the Linux kernel team

Which very notably does NOT use C++.

[csdreamer7]

Nor does Postgres.

[jesse__]

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.

[Yoric]

My anecdotal experience is the opposite.

I write code much faster in Rust than in C++. Part of it is thanks to the type system – fewer opportunities for dev errors means that I can produce code that is more concise, spends less time handling runtime errors because I can have static guarantees that they have already been handled somewhere, etc. Part of it is #[derive(...)], great documentation, Cargo and other QoL components of Rust.

[jesse__]

Fair enough. I can imagine if you largely write code that plays nice with the compiler it could be faster. That just hasn't been my experience.

[__jem]

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

Why is this your exercise you have in mind though? This is such a bad argument. Like, yes, if you work at doublylinkedlist.com where your entire job is writing a new linked list implementation every day of the week, Rust might be a bad choice. But that's not what any kind of commercial enterprise actually looks like. If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.

[jesse__]

>> Why is this your exercise you have in mind though?

That was an example I could point to where the code size difference between Rust and C or C++ is roughly 10x. I mentioned it to corroborate the claim that sometimes writing Rust is very verbose, on the order of ten times more.

My point was not that average commercial codebases are largely dominated my these types of structures. My point was that my experience with Rust has been that the development slowdown is much more than 5%, as the OP suggested.

>> If I saw you writing a lockless thread queue at work, I'd tell you to stop wasting time.

And that's one reason we don't work together ;)

[pkulak]

A lockless thread queue (not entirely sure what that would be, sorry; a queue in front of a pool?) seems like the kind of low-level library that could be written with liberal use of unsafe. No need to flagellate yourself on the altar of compile-time safety.

[jesse__]

Then why would I use rust in the first place?

[jackmott42]

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)

[ttfkam]

And you're running at least one static analysis tool and a linter on your C++ code too, right? You're not just deploying the C++ compiler output as-is, right?

Those take time to run too and should absolutely be added to the compile time metrics when comparing against "cargo build".

[kajaktum]

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

Do they have an equivalent API? Rust does have a hard time explaining very, very low level stuff that you'd have to do unsafe and various magicks. But once you get the unsafe details right, the consumer API for them tends to be extremely rigid and fool proof.

[jnordwick]

> Rust does have a hard time explaining very, very low level stuff

A little odd for a supposed system langauge

[mcronce]

This is an ... interesting argument. "I can't write this 200LOC component of a large codebase in safe Rust, so what's the point in Rust?"

[3a2d29]

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

Safe rust would have caught. If you had to drop into unsafe to do what they did, the serious security bugs would still have happened.

[jackmott42]

A fair point, though the few security issues in recent years I've looked at were not the kind of thing you would turn to unsafe rust for. But I've certainly not done a broad enough sampling to say what % of cases are like that.

[3a2d29]

To be fair, I am sure Rust catches a fair amount (compared to C++ which would catch 0). I just think that phrasing rust has having 0 memory errors can be a tad inaccurate.

[ttfkam]

Except when something goes wrong, you can typically focus all your attention on the unsafe blocks, which should be a very small portion of your codebase, if it exists at all. (Contrary to popular belief, unsafe Rust code is neither mandatory nor widespread.)

By contrast and comparing apples to apples, your entire C or C++ codebase is the equivalent of one giant unsafe block. You can bring in 3rd party tools to perform some of the static analysis the Rust compiler does for you, but call it for what it is.

By default, Rust is safe while C & C++ are not.

[boris]

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

I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint penalty), is it perhaps worth staying with C/C++ and spending more development time on testing/fuzzing?

[duckerude]

Some people make the opposite claim: Rust lets you get away with less dynamic allocation (and more data shared between threads) because you can rely on the compiler checking your work.

The effect might be positive or negative depending on the circumstances.

[smolder]

If you're willing to jump back to C++ to get around the borrow checker strictness, couldn't you just use Rust's unsafe block where you're sure it won't result in a bug?

Is it harder to fuzz Rust? Honest question, because fuzzing is something I occasionally read about but am not practiced in.

[duckerude]

I've found it very easy to get started with fuzzing in Rust using cargo-fuzz. I didn't do anything very advanced, and my closest point of reference is testing Python with Hypothesis, but it did turn up bugs.

Here's a Rust fuzzing story from yesterday: https://hacks.mozilla.org/2022/06/fuzzing-rust-minidump-for-...

It claims that Rust is particularly suitable for it because integer overflow panics in debug builds (and out of bounds indexing always panics), which sounds reasonable.

[jackmott42]

That is a fair thing to wonder about, but at the moment most of the design decisions Rust pushes you toward tend to be better for performance on modern hardware. For instance using an array based arena to store a graph, instead of the traditional allocation of a chunk of memory per node on the heap. Or just keeping more stuff on the stack.

[jnordwick]

But it takes a lookup hit and you need an arena per object type with its memory overheard. You'll get more cache misses.

A lot of the rust performance talking points just aren't true. Rust is slower than C and C++, not by much but you can't get a true believe to even recognized this. Rust has turned into a religion.

Rust also disallows some things that you can do fine on C++ if you know our architecture because thing won't work on some machine 20 years ago (eg, it has more strict alignment requirements than any machine a consumer can see).

Throughput may only be 5% or more slower, but latency issues for rust is a much bigger issue. The devs I've talked to don't even try to pretend they have a good latency profile.

[staticassertion]

The linux kernel is absolutely anything other than high quality lol

[strictfp]

I've worked in a variety of languages, and returning to a c++ project recently I do see that we spend a lot more time thinking about how to write the code in a way that avoids problems. Meaning that there's a lot more architecturing required to reach a sane state.

We have a sister product written in a dynamic language, and sometimes we have identical functionality.

I've noticed that when a change is discussed, the c++ gang has architectured themselves into the current solution and therefore have a much harder time making changes.

So for that reason I think it's easy to overlook these complexities when you're working in c++ alone; they feel natural and are just part of how you work. You forget that a lot of this architecturing just isn't necessary in a lot of other languages.

[jstimpfle]

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.

[strictfp]

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 is in my eyes sometimes overdoing it. If you for instance use Rust, you can be a lot more confident that the compiler catches these issues, and be more conservative and efficient in the solution.

[jandrewrogers]

> very biased towards virtual methods

This is a function of the type of software you write. There are many large C++ code bases that rely on various types of static polymorphism almost exclusively, rarely having a use case for virtual methods or dynamic polymorphism. There is a similar story with inheritance versus composition; some types of code bases naturally gravitate toward one or the other.

The nice thing about C++ is that it as amenable to any of these models should it benefit the application.

[jhgb]

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

[ryl00]

> Creating trees or graphs can be cumbersome

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

[leni536]

Sometimes (definitely not always) you can use std::function instead for dynamic polymorphism.

[cyber_kinetist]

…and when you do need a large number of dynamically allocced/deallocced objects, then using indices to arrays instead of pointers. Which kinda defeats the purpose of using the Rust borrow checker…

[xyzzy123]

I think this mirrors my day to day experience with C++.

On the other hand, fuzzing large c++ programs will routinely uncover memory safety issues in practically any large codebase that hasn't been absolutely beaten to death by fuzzers already.

The issues are not usually so much "I returned this thing on the stack" they tend to be things like "this (very unexpected) sequence of api calls will result in a UAF in this deeply nested data structure over here on the heap".

[lmm]

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

Everyone claims this, probably because business logic bugs are more memorable. But I've never seen it match the real statistics. According to the best published data, null alone is something like 30-70% of bugs, you just don't remember them because they're uninteresting.

[Macha]

It depends on the person's mental categorisation of bugs too. For example I could see someone classifying null bugs as business logic bugs because "the business logic didn't account for that information not always being there"

[jhgb]

It's a language bug, really. If you're expected to say what the individual things in your program are allowed to be (like you have to in C++, Java, C# etc.), and you say "foo is a BarBaz object", and the language and compiler allow you to set foo to something that isn't actually a BarBaz object and this is considered OK, then the language is botched.

[akhmatova]

There are and never will be (meaningful) statistics for the "N percent of bugs are caused by X" question.

Every org's use cases are different, how do you get (let alone compare) data frm different orgs, who really counts their bugs anyway (and those that do at scale and in detail are probably doing suffering from some form of myopic management disorder or another), etc.

All you can do is ask people their gut take based on their particular experience. For systems engineers, a lot of bugs are due to memory safety. For more consumer-oriented startups (or in most any bigcorp), yeah, it's "business logic" (or people's inability / unwillingness to communicate), etc.

"We found that 70 percent of our bugs could have been prevented by moving to TypeScript", yeah sure.

[capitainenemo]

I wonder if passing NaN is considered "business logic" Thinking of this interesting exchange long ago by an experienced c++ dev

https://old.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...

[mwcampbell]

Counterpoint: When I was on the Windows accessibility team at Microsoft, one of my most brilliant colleagues gave a presentation about what to look for when doing code reviews, and he emphasized three main categories: C++, COM (Microsoft's Component Object Model), and concurrency. Rust eliminates many of the issues in the first and third categories. And yes, we were writing modern C++ as much as we could in that legacy codebase; by 2019 we were using several C++17 features, as well as the latest C++ utility libraries for working with COM and WinRT. Given the state of the Rust windows crate, that team (which both I and that colleague left in late 2020) might even be able to use Rust in new code. I'm sure that would make him happy.

[bestouff]

My manager told me exactly the same thing as you do; after I found a few UB in its code in the first 2 weeks he changed its stance.

[josefx]

I had to deal with a senior dev. that gave me a talk about seniority after I ran valgrind over our software. Guy was so deep into the whole senior dev. power trip that he blamed third party libraries for his bugs, dev. tools for "incorrectly" identifying his bugs and wrote more bugs to work around his other bugs.

Finding and fixing issues in C++ code can be easy with the available tools, getting people to use them on the other hand can can be like talking to a wall.

[darthrupert]

That sounds more like an expert beginner than senior.

[im3w1l]

Sounds like someone who senses his place in the hierarchy is threatened.

[staticassertion]

Unsurprisingly the types of bugs reported are going to be around business logic errors and not obscure edge case that users won't run into naturally. The bugs are still there though.

[hgomersall]

Right, and if you come across it you can't always reproduce it. "Oh it crashed, yeah it does that sometimes".

[nemothekid]

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

[ostenning]

Can you elaborate on the proficiency of your dev team, is this with juniors etc? Is it a large team? And what is the complexity of the project? I think this is important information

[shuger]

GPU driver, most devs are senior. Hundreds of thousands of lines of code in the "slice" my team is interested in. Team for our component has on it's own has probably over 40 people.

Driver should be even more prone to programming bugs because most of it is about manipulating data in raw "untyped" memory.

[the_mitsuhiko]

GPU drivers are also some of the most buggiest stuff out there I used. When I worked in Games we routinely managed to make the GPU drivers crash which thankfully at the time was already no longer taking down your engine machine.

[Daishiman]

My experience with GPU drivers then is that your code is likely buggy AF and your team is in denial.

[Agingcoder]

In practice for you. Where I am, things are very different! Buffer overflows and memory corruptions, threading issues, uninitialized variables, etc appear on a very regular basis, and end up being very difficult to debug, mostly because the moment where you corrupt memory and the moment it triggers a bug can be very far apart.

[flohofwoe]

Static analyzers can catch this stuff nowaways (in this case clang's builtin analyzer):

https://godbolt.org/z/1MfErrYd8

...in more simple cases it's also a regular warning:

https://godbolt.org/z/5v9YsWd4j

[kevincox]

> less time debugging

I would say it isn't even the debugging. As many of the C++ programmers here have said as you get good at C++ this becomes something that you are vigilant for and it rarely actually gets written. But just the lack of even needing to think about it is a huge load off my mind. When I used to write C++ I never really realized how vigilant I was. Every time I added code into the middle of a function I had to double check all of the lifetimes, every time I shorted the lifetime of a variable I had to search for it to the end of the function. Just not having to worry about this much really frees your mind for thinking about other things.

[blub]

And what are you thinking about now?

For me it was what lifetimes and types to use to make my program work. Just as it was in C++, but with a static verification step at the end which most of the time got in my way.

Rust makes lots of sense in high-churn projects or projects which have very high security requirements (like browsers). Otherwise I’d think carefully about using it.

[dralley]

You had to think about lifetimes in C++, too, but in Rust at least they're written down and enforced.

[blub]

I find neither C++ nor Rust to be particularly “creative” programming languages because one has to think all the time about two things which are irrelevant for the features of the program - resource management and complicated types.

Rust is even worse than C++ because it highly encourages encoding logic in types and the community loves doing that.

You seem to have almost come to the same conclusion yourself, but then mistakenly assume that the same kind of productivity of a GC language is available in a system language. Nope. Although at least in C++ one can just say “fuck it” during the “creative” prototyping phase, copy most things and still have decent syntax and performance. In Rust you’d have to pepper everything with clone, boxes and (a)rc, so you'd have another mess.

[hinkley]

The exhausting part for me was always when the bug escapes detection for a little while, is associated with some new functionality that very much did not escape detection, and it turns out that the wrong implementation is faster than possible. Now to fix the bug I get to be the bad guy and take away the customers toys (one of many many reasons to push for making the culprit fix the problem, especially if they don't want to).

It doesn't take many of these to form a coping mechanism that prevents this from happening again, even if it's at great cost. This is also the genesis of many unwinnable arguments that drag on forever.

[phendrenad2]

Nope. In my experience, Rust saves you from very common obvious errors that junior programmers make, certainly not 10x programmers who have been writing C for a long time. It's great when you're starting out (which is why it's massively popular with new graduates or people who are just learning to program), but at some point it's questionable if the hand-holding Rust gives you is worth the extra development time overhead, more complex syntax, etc.

It also depends on what you're writing. If you're writing cryptographic routines, or protocol handshaking, the tradeoffs are heavily weighted in Rust's favor.

[hardex]

For the unironic use of "10x programmer", I'm hereby sentencing you to death.

[ttfkam]

Yep, all those kernel, driver, and database devs out there are all junior devs just starting out. No way anyone with decades of experience will introduce a remote exploit or crashing bug in their C programs and libraries. Never happens. No CVEs to see here! Move along!

/s

[phendrenad2]

Why do you think this is a valid argument? Are you saying there are no junior devs working on databases, kernels, drivers? What evidence do you propose to back up that astounding claim?

[ekidd]

> All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope.

That's the root cause, but it's not the interesting bit.

The code in the article comes from a production compiler. And normally, the AST (abstract syntax tree) is a single data structure output by the parser. Ownership is simple: the entire AST has the same lifetime, and it's managed by a caller. This should be easy, right?

But it turned out that there was a piece of code that sometimes "synthesized" extra, temporary AST nodes. And these nodes had a shorter lifetime than the rest of the AST.

These are vicious bugs. You have some long-standing convention about how things work, but one little piece of code makes an exception (often for excellent reasons). Then another module decides to make an aggressive optimization that relies on the original assumption. But that assumption is now true only 99% of the time.

It's a communication failure, and it might take years to actually turn into a bug. And that bug may manifest as extremely rare memory corruption that shows up in automated crash reports.

Running down this kind of phantom memory corruption is one of the most frustrating things I've ever done. It often involved spending weeks staring at minidumps, looking for interesting patterns in crashes. There's that horrible moment when you realize that 20% of your crashes occur within a thousand instructions after a particular font-rendering function reports an error, accidentally corrupting the exception-unwinding machinery.

And sure, I get it. Maybe your team is simply good enough that nobody ever makes a mistake like this. But if so, they're exceptional. I've worked on amazing teams that still get bitten by subtle miscommunications and misunderstandings.

[fleventynine]

Reviewing commits for a security-critical project written in C or C++ can be incredibly tedious. I've spent an entire day trying to validate that the assumptions made by a 10-line change are memory-safe in the context of the larger program. These reviews are incredibly mentally draining, and even when I'm done I'm not 100% sure that I didn't miss something and let a vulnerability into the codebase.

Rust is a breath of fresh air in comparison. Worrying about memory safety isn't even a concern for the vast majority of commits that don't touch modules with unsafe code. All assumptions made about the lifetimes of references are made explicit in the code, and checked by the compiler. On rust projects I find I have much more mental energy to use against other aspects of the problem.

[renox]

I agree with you on the first point, but I totally disagree with you on the second point: sure if you know how to reliably reproduce an issue it isn't complicated to debug, but this kind of issue can be difficult to reproduce, can create silent issues..

[est31]

> You get corrupted data, set data breakpoint and in the provided example you will see it being modified by unrelated operations on stack.

That's provided that you can even reproduce the issue well, especially in an instrumented build which might be way slower than the non instrumented one. Often you get bug reports like "crash after one hour of usage" where basically every feature of the app has been heavily used by multiple users. Rust applications might still crash but they crash safely, which means your error messages are more meaningful.

[atoav]

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.

[MaulingMonkey]

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/

[DrBazza]

Just because Rust, in particular, compiles successfully, that's no guarantee that the code isn't complex and difficult to understand. I can write a complex badly designed app in any language. Similarly I can write simple well designed large applications in any language too.

[ChadNauseam]

Yeah, but that doesn’t mean all languages are created equal in that department. Let’s take this pseudocode:

    int a = 0;
    if (findindex(mylist, myvalue, &a)) { 
        // dostuff with a
    }

Here, findindex returns false if it can’t find the value. The problem is that there’s nothing forcing you to use the if, you can just forget it and you’ll be left with incorrect code. In Rust, this type of error is impossible to make by accident, because the findindex function would return an Option, and you have to explicitly handle both cases (or explicitly say you don’t care about one of the cases).

Things like that, along with the lifetime system, make it easier to write good code. It’s like saying that it’s possible to destroy your foot with a shotgun and with a pencil – it’s possible, but it’s a lot easier do to by accident with the shotgun.

[Daishiman]

This fallacy gets repeated over and over again and it doesn't make it any less false.

Languages are tools and some tools are actually better-built than others. If we can claim that a language like Brainfuck makes writing clear code extremely difficult, and Python or Rust make writing clear code easier, we've already established that there's a spectrum for language in expressiveness and clarity.

Eliminating entire classes of bugs makes for better understanding.

[lelanthran]

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

[MaulingMonkey]

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

[lelanthran]

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-ish product written in C++03.

I went through about 3 years of tickets (limited to only the bugs reported). No open ticket was older than a few weeks. Out of maybe 1000 bugs, only a single one was something Rust would have prevented. I would think that most mature products will have similar stats, so the trade-off is not as obvious as it looks to be on the surface.

Deliverables matter.

[vgel]

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.

[lelanthran]

I'm not saying that a large number of CVEs won't be prevented in Rust, I'm saying that so few bugs are CVEs that the trade-off is not always worth it.

If you have 1000s of bug reports, of which 5 are CVEs, and then have 3 of those 5 be preventable, most dev teams are still going to consider the cost/benefit of going through the pain of developing a long-term product in Rust, or of switching to Rust altogether.

[bschwindHN]

> of which 5 are CVEs

Those 5 are just the ones you know about...

[lelanthran]

> Those 5 are just the ones you know about...

It's pointless making a cost/benefit analysis on things that probably don't exist.

[girvo]

I suppose it comes down to risk assessment; if those CVEs are critical “fix this now or the world catches fire”, then their relative infrequency seems to be outweighed by their impact, no?

[lelanthran]

> I suppose it comes down to risk assessment; if those CVEs are critical “fix this now or the world catches fire”, then their relative infrequency seems to be outweighed by their impact, no?

No.

[snovv_crash]

CVEs are a tiny, tiny fraction of bugs.

[nemothekid]

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

[Daishiman]

What is it about C++ as a community where most average devs claim an inhuman level of proficiency but only the coders with experience in real critical codebases have the humility to claim that without extremely strict coding practices and extensive use of fuzzers we're barely smarter than apes at churning out safe code?

[SloopJon]

> All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope.

The author isn't just telling you that Rust is awesome because it tells you something, he's acknowledging the frustration in learning how to listen to the compiler.

It's kind of like Jerry Pournelle describing the ups and downs of USB by documenting an epic journey that all started with trying to scan some handwritten notes for his next novel using a Canon scanner he borrowed from Alex that he's just now getting around to reviewing, because the pins of the parallel port are too bent to use the old Epson. Okay, so maybe it was a little overcomplicated.

[cbarrick]

Earlier this month we integrated a C++ library written by my team with a server written by another team.

We saw the data corruption, and we knew it was a reference issue, but it took quite a bit of effort to track down. The cause was confusion around string_view and string&, with different behavior when you pass each to a new thread.

Rust would have caught this much earlier and saved 3 days work.

[grogers]

This case might be trivial to debug, but when you start adding concurrency a lot of that ease goes out the window. Right now, our tests are mildly flaky because of asan crashes from use after stack frame issues. Reading the code it should be joining all the coroutines on destruction, but yet the asan violations are happening. It really isn't that trivial to debug. Luckily in our case it doesn't affect production since it's only on shutdown (probably...?).

[zh3]

As someone considering learning Rust, the article put me off fast with the long preamble to even explaining what the issue was. I really hope it's not that complicated, but even your rebuttal fills me with fear - "corrupted data [......] being modified by unrelated operations on stack". How would you explain that to put a C programmers mind at ease?

[ArrayBoundCheck]

It's unfortunate how many upvotes this got from the title