This is definitely into the territory of misinformation.
I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in
I already addressed this before. Regular crashes are almost always (I can’t remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs’ stability to ‘any other compiled language tools I use are written in’ is very disingenuous - because it’s just as easy to handle those errors and prevent a crash at all.
If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust
You are unnecessarily conflating issues here. ‘Most modern languages’ are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their ‘systems programming language’ tag, for example. If a GC language meets your requirements - then by all means, use it. But it’s not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It’s not something to dismiss as trivial.
And while at it, you neglecting what segfaults represent. It’s just a benign example of memory safety bug. It’s benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.
If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.
I really don’t want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as ‘any other prolang’ is to neglect idiomatic Rust. That isn’t surprising because crashing anything is possible if that’s your intention.
I think you’re missing the point where I said I don’t write Rust. I’m merely making an observation - as a user who’s more than usual, probably, aware of which language any given tool is written in, of what I observe.
I know I’ve seen a Rust program segfault, and I’m certain that I saw this only once. I’m equally confident that almost every other segfault has been from C/C++ code, but not other languages.
What I’m hearing you say is that crashes aren’t a risk, per se, as long as they aren’t memory related and so the crashes I see from Rust programs don’t count because they aren’t segmentation faults. Did I read that right? And I also hear you claiming that, e.g., NPEs are security issues, even if the runtime catches them and safely exits the program in a controlled manner (“crashing out” safely) - is that right?
This is definitely into the territory of misinformation.
I already addressed this before. Regular crashes are almost always (I can’t remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs’ stability to ‘any other compiled language tools I use are written in’ is very disingenuous - because it’s just as easy to handle those errors and prevent a crash at all.
You are unnecessarily conflating issues here. ‘Most modern languages’ are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their ‘systems programming language’ tag, for example. If a GC language meets your requirements - then by all means, use it. But it’s not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It’s not something to dismiss as trivial.
And while at it, you neglecting what segfaults represent. It’s just a benign example of memory safety bug. It’s benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.
I really don’t want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as ‘any other prolang’ is to neglect idiomatic Rust. That isn’t surprising because crashing anything is possible if that’s your intention.
I think you’re missing the point where I said I don’t write Rust. I’m merely making an observation - as a user who’s more than usual, probably, aware of which language any given tool is written in, of what I observe.
I know I’ve seen a Rust program segfault, and I’m certain that I saw this only once. I’m equally confident that almost every other segfault has been from C/C++ code, but not other languages.
What I’m hearing you say is that crashes aren’t a risk, per se, as long as they aren’t memory related and so the crashes I see from Rust programs don’t count because they aren’t segmentation faults. Did I read that right? And I also hear you claiming that, e.g., NPEs are security issues, even if the runtime catches them and safely exits the program in a controlled manner (“crashing out” safely) - is that right?