I still find this type of comment odd (although I do also recognise that it's very common).

I write a lot of code in C++. And I'm definitely no fan of it, so I'm not here to defend it! And I write a lot of bugs in that code. But very few of them are segfaults. With smart pointers and some common sense, they're just not that big of a concern. Yes, they do happen, but it's far a minority of the bugs. Maybe everyone just has better tests than me? (shrug)

I like the look of Rust, though I haven't yet got to use it professionally. 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). It would probably be good enough for most purposes, and the improved uptake would result in fewer bugs overall than the current situation.

It's academic really since that's obviously not where we are. But, like I say, I don't think memory errors are that problematic in C++ in practice (unless you're writing security sensitive code where even an occasional one can cause big problems).

> 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

This kinda counter-resonates with me. I'm not a superb programmer by any means, but C's memory management rarely caused me bad problems. I find it much easier to deal with than the complexity of languages like C++ and Rust.

Calling malloc isn't even manual memory management to me, it's just calling malloc. Writing malloc (not that hard in general! but tricky to get exactly the allocator performance or security properties you want for your use case) is manual memory management.

> In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage.

https://en.wikipedia.org/wiki/Manual_memory_management

So, you can call it however you like, but calling `malloc()`/`free()` manually (emphasis on the `free()`, since allocation is explicit in most languages in form of `new` or something) is manual memory management, and this is how most programmers use this term.

Why did you think this added to the conversation?

I understand the comparison with C (the memory management) but I wonder how do you compare Rust to Java? What is it that makes you feel more confident in Rust compared to Java?

Java _used_ to give me that "it just works" feeling when I started using it... in 1999. The rich type system makes the biggest difference. In Rust, you can solve a problem by first modelling it through structs and enums and then define operations pertaining to elements of the model. rustc (the compiler) has such a grasp on the implications of a given model that it will most often guide you toward a near-optimal (and safe) solution that ends up working flawlessly the first time you get it running.

Rust has a cool type system, but I think you give it much more credit, like it doesn’t have dependent types where the implementation can often be filled in literally.

Other than checking mutability and nullness, I really don’t think that Rust would be that much ahead compared to even an “older” language like Java.

Also, java now has ADTs so “exhaustive checks” are available there as well.

I can't compare with Java, but I can for C#. With Rust I find that I have much more confidence that I understand what the code is doing primarily due to the borrow checker and how Rust enforces unique vs shared access vs ownership. Just by knowing the types involved, I know exactly what a function could potentially do to what I pass in just by looking at the call site.

In C#, I can't tell at the call site whether a function could mutate what I pass in; not without looking at the implementation of the function and anything it passes that object to. With Rust, how it's passed in completely informs me about this. If it's passed by shared reference, it can't mutate. If it's passed by unique reference, it might mutate. If it's passed by ownership, then I can't access the instance any more anyway, so it's not my problem.

I think you shouldn't compare Rust to Java (the language), you should compare it to Java (the ecosystem). The JVM is rock solid and very performant, and you have languages like Java++ (called Kotlin) and Haskell# (called Scala), or even Common Scheme (called Clojure). The same is true for the ecosystem, eg. build tools (Maven/Gradle are the default ones, but there are many more), frameworks (Spring + all the reactive stuff), the largest number of libraries on the planet after C, and so on.

The target niche is not exactly the same though, you wouldn't want to systems program on the JVM, and it would probably not make much sense to choose Rust over Spring Boot for web programming. YMMV of course.

You're right that with regards to memory management, using Java over Rust doesn't make me any more nervous. The things I really miss are at the type level. Small things like the compiler forcing you to be explicit about mutability. Large things like Rust enums and pattern matching which make it easy to model complex workflows without worrying about missing any cases.

Let me also make clear that I like the direction Java is moving (even if is taking decades) For example, something I look forward to in Java is pattern matching on switch expressions, which just got added as a preview feature in the latest LTS.

No null pointers, and no data races when you're working with threads.

Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?

The myth of segmentation faults being hard needs to die. A fault is like an exception in Java (or a panic in Rust for that matter), only generated by hardware. It's the best case scenario for your buggy code. It's when you don't get a segfault, but your buggy code keeps chugging along, that's a problem. If after using an out-of-bounds index into an array I get a segfault instead of a memory corruption, I thank god for his mercy. The alternative of the program just continuing execution is horrible.

Segfault is only best-case scenario if it happens at the location with the bug.

It is extremely common to start diagnosing a segfault and find that the location of the segfault, in code, is unrelated to the code which caused the segfault.

Agreed.

My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory for corruption - it can really narrow down the possibilities.

I always enjoyed the mystery. It's a puzzle with an as-yet unknown solution. How can you not love it?

In cases when I have a working visual debugger, I agree, it's fun. Without one, it's not fun.

Oh yes, for sure. Visual debuggers make things so much easier! It might be worth pointing out that visual debuggers have been around for well over 30 years at this point.

when do you not have one ? as soon as you have a mere hint of gdb / gdbserver possible you can debug in a GUI such as Qt Creator's

A couple situations.

Sometimes you can end up in a pickle because the embedded system you’re working with just doesn’t have a good debugger available, or it may be cumbersome to set up.

Sometimes the segfault happens in a production environment and you just can’t hook up a visual debugger to the ten different instances of the server you’re running.

I agree that a segfault is a fun error to try and diagnose because it really exercises your gray matter. But it’s not my job to diagnose segfaults, it’s my job to keep the service running up to some certain standard, and if I find myself diagnosing lots of segfaults, there is usually something else I could be doing involving instrumentation or testing to address those defects which is more boring but more productive :-)

Depends, if it happens in prod, you are **

If it doesn't happen in prod, you are even more **. Cue password leaks, privilege escalation etc.

Fair enough.

Sticking to STL in C++ and avoiding pointers unless really necessary will significantly cut down on segmentation faults.

It has been many years since I spent "hours debugging" a segfault. But I use C++, not C.

(That said, I coded C from 2008 to 2012, and spent no hours on segfaults then, either.)

I am a professional C++ programmer and I can’t even remember the last time I had a segfault. I also haven’t had a bug in production the last 5 years. But YMMV of course.

This is quite rare in C++ since C++11.

Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters.

Scala has the same problem. Stop writing your own DSLs!

> Stop writing your own DSLs!

100% disagree. Writing custom DSLs is how you get the best programs.