>So, it's not that "all languages" are like that. That seems like a "moving the goalpost" type of logical fallacy.

I think what's mean is that Rust's type system only removes one specific kind of unsafety, but if you're clueless you can still royally screw things up, in any language. No type system can stop you from hosing a database by doing things in the wrong order, say. Whether trading <insert any given combination of things Rust does that you don't like> for that additional safety is worth it is IMO a more interesting question than whether it exists at all.

Personally, I mostly agree with you. I don't much care for traits, or the lack of overloading and OO, or how fast Rust is still evolving, and wish I could have Rust's safety guarantees in a language that was more like C++. It really feels like you could get 90% of the way there without doing anything too radical, just forbidding a handful of problematic features; a few off the top of my head: naked pointers, pointer arithmetic, manual memory management, not checking array accesses by default, not initializing variables by default, allowing switches to be non-exhaustive.

▲

einpoklum 4 days ago | parent [-]

> only removes one specific kind of unsafety

the word "only" doesn't really belong in that sentence, because these are very common in root-cause analysis of flaws by the "Common Weakness Enumeration" initiative:

https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

and having said that - I agree with you back :-) ... in fact, I think this is basically "the plan" for C++ regarding security: They'll make some static analysis warnings be considered errors for parts of your code marked "safe", and let them fly in areas marked "unsafe".

If the C++ committe can make that stick - in the public discourse and in US government circles I guess - then they will have essentially "eaten Rust's lunch". Because Rust is quite restrictive, it's somewhat of a moving target, it's kind of fussy w.r.t. use on older systems, and - it's said to be somewhat restrictive. If you take away its main selling point of safety-by-default, then there would probably not be enough of a motivation to drop C++, decades of backwards compatibility, and a huge amount of C++ and C libraries, in favor of Rust.

And this would not be the first time C++ is eating the lunch of a potential successor/competitor language; D comes to mind.

	▲	fluoridation 4 days ago \| parent [-]
		Sure, but those are lists of weaknesses, not of bugs. Of course most of them would be memory errors. A program can play entirely by the rules and still display incorrect behavior. Consider for example the Mars Climate Orbiter bug. No amount of memory safety could have prevented that (although C++ could have been able to encode the unit information in its type system).