> But very few of them are segfaults. With smart pointers and some common sense, they're just not that big of a concern.

I think it's really a POV thing. Rust surfaces those concerns very directly, even if it would have been correct 99.999999% of the time, Rust will enforce another decile of correctness. Since it does this quite aggressively Rust's users tend to have their mind (mine included) a bit (over)fixated on those issues.

(also, in Rust you don't use common sense, you use the compiler, and imo that's great, my common sense has failed me enough)

Rust's "lifetime stuff" really is overemphasized. You can write years of totally ok Rust code without ever having to handle a single explicit lifetime. They're there, and one should have a general picture of how they work, but unless you're doing high perf / library stuff, they can generally be sidestepped.

I believe there should be a Rust manual that shows the easy way in, using Rc/RefCell before reaching for plain references. So many people get the idea that if you're not using the hardcore smallest construct to extract that very littlest bit of performance, you're "doing Rust wrong". The overall idea of Rust is that of safe code and although the compiler and language semantics obviously play a major part in it, the standard lib is actually very nice too and helps a lot to get away from the harsh realities of bare system programming.

You're benefiting from elision. Modern Rust lets you omit mention of a lifetime when there's only one plausible choice. So, often today you can write Rust that doesn't mention lifetimes but they're implied.

But it wasn't always like that. For a while Rust would insist you spell out that OK, this function parameter has some lifetime 't and the function result also has a lifetime 't. Now, Rust says well, the result needs a lifetime, and your function takes one parameter which also has a lifetime you didn't specify, so, the plausible explanation is that they're just the same lifetime, let's assume that's what you wanted and only complain if that won't compile.

> I actually think it would be a perfectly good language without all the lifetime stuff, with lots of improvements over C++ (destructive move for a start).

I'm not sure what you mean by this exactly. Do you mean Rust would be a perfectly good language without its safety guarantees? Because it can't have them without lifetimes. It could instead have GC like Go/Java/etc, but now it's a GC language.

Lifetimes aren't a feature of the language. They are the implementation details for a couple features of the language. It's how it gets there. And I don't think Rust would have anywhere near the interest it has without those features.

It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Ha! Fair point.

Two counter points:

* As other comments have mentioned, security bugs matter more in some products than others. (E.g. think of a desktop application connecting to an organisation's own database.)

* That includes a whole lot of code (maybe the majority) which is either C or C++ from before C++11, given that the bugs were tracked in the period 2006 - 2018. Never mind a hypothetical Rust-without-lifetimes.

70% of all security issues is not 70% of all bugs. For the large majority of software products, security issues are an infinitesimal minority of bugs, and arguably, for a significant chunk of software products, security issues are not even critical.

I should have said: for a significant chunk of software products, there cannot even be security issues at all. If you disagree, just look around, preferably outside a "network service" mindset.

That's 70% of CVEs, not 70% of all bugs, which is a massive difference. Most programmers don't deal with CVE worthy bugs on a daily basis, no matter what programming language they use.

It's fact that it's easiest to cause a CVE bug in a language that you manually manage memory. So it's true that most likely JavaScript programmers may not cause them too often ;)

Anectodal, but: I had been working on a mixed C/C++ code base which grew over around 20 years to about 1mloc, with a team of programmers varying between 5 and 20, and we had to deal with memory corruption issues around once or twice a year, and those could be solved relatively quickly (even more quickly with modern memory debugging tools like the memory debugger/profiler in Visual Studio).

At the same time, the bug database for the project had a "throughput" of about 5..10 bugs per day (for the programming team, many more for the entire team). The amount of memory related bugs relative to "regular" bugs is infinitesimal even in a C/C++ code base.

Of course I realize that the code base had "sleeper bugs" that hadn't showed up yet, and a memory safe language would have helped to prevent those. But I just wanted to point out that memory corruption issues are just not a daily topic in most C/C++ projects.

In the end, safety comes down to the sandbox your code runs in (for instance operating system processes, or Javascript VMs). Should those sandboxes be written in Rust? Most likely yes. Should everything else be written in Rust? Nah...

Case in point, no? How many companies need to use a programming language with manual memory management?

This is why we need a professional organization to hold software developers accountable to the same standard as other fields of engineering.

For this to work, you'd need most of the code to be written by people who are paid (i.e. professionals).

In my experience somewhere between 50-80% of code at most places is stuff pulled off maven/npm/github/etc written by people who are completely uncompensated, and possibly as hobby projects.

You could censure devs pulling in unverified code, but so far as I can tell, the vast majority of devs are really bad at reading code. I'm doubtful it would change anything.

This seems like something that should maybe covered in a computer science curriculum, but most colleges seem to have an aversion to becoming "job training" centers. If they don't start teaching it, I'm not sure how you can expect people to have training in it. Do we need a training course outside the traditional university system?

The problem with this idea has been the same for 40 years: unlike in other fields of engineering in Software there is no bedrock of empirical science from which we can derive objective, reasonable standards. It is all opinion in CS and no doubt the most obnoxious, useless methodologists would be the ones with the strongest opinions about how others should build things.

I would love a world where that would happen; and also get years of testing, proof of concept time and funding to make all that actually happen. Not counting on it thoug since cost would skyrocket.

Well, software developers will need 2/3 years of legal training also then.

Both you and parent are correct. Memory safety issues in c++ code are common, but very often they don't manifest as segfaults. Malloc assertion failures or occasional data corruption in edge cases or "impossible" behavior are more typical symptoms.

Memory issues are rare in every C++ project I’ve ever worked on when compared to much more common bugs in expected functionality (the biggest category), bugs introduced by new or updated libraries, or operating system deprecations, etc.

Overall, the aversion to C++ and other non-GC languages is overly stated in the industry by vendors looking desperate for a problem to solve to validate using their new language or as a solution for companies that want to hire large armies of sub-par developers to bang on keyboards.

@hellokittycity

There are ideas like that

https://it.slashdot.org/story/22/06/13/0134242/two-tech-ceos...

This exactly.. we need to be able to have accountability. Agreed