* Just because I'm more comfortable with types doesn't mean that everyone else is.
* Someone may want to do something in a type system which is well typed, but only in a different type system.
* Someone may want to do something in a a type system which is well typed, but which has some bad compilation characteristics for the given type system.
Even if Rust is objectively better, you still have to get used to the things about it that make it objectively better. And you have to keep up with the changes that are made to it. And you have to understand where those better things fail down (for example Non Lexical Lifetimes ... in which case you have to get used to the NLL acronym that people use).
A simpler language, even if objectively worse, can yield better results if it is used with discipline. Discipline that might be easier to hone with less things that need to be considered.
And sometimes better results don't actually matter because the goal isn't the best results tomorrow but reasonably adequate results today.
http://archive.adaic.com/intro/ada-vs-c/cada_art.pdf
I'll also add that Rust can give you both memory safety and race freedom at compile time. If you debugged heisenbugs, then you know that's a huge benefit. On Lobsters, one guy mentioned being hired for (a year?) to find and fix one in a system. Eiffel's SCOOP had a similar benefit. Languages such as Chapel made parallelism super easy in many forms vs C++ and MPI. Used judiciously, macros can eliminate tons of boilerplate. Erlang's strategy for error handling might go in this list if reliability is a goal.
There's been quite a few examples were a difference choice in language design eliminates entire classes of problems with anything from no effort to significant effort by developer. Increased velocity with fewer bugs during feature integrations and maintenance are provably-beneficial metrics for a business. I think we can say there's scientific evidence of actual benefits from language choices which have potential benefits if used in business. I just can't tell how far, if any, you'll get ahead by using them since there's non-language-design factors to consider that might dominate.
The large uptake and excitement around Rust shows that there are many C and C++ programmers who appreciate the safety guarantees that it provides. The popularity of Rust has actually created a resurgence of interest in Ada and each language has benefitted from the other.
For example, Spark, a well-defined subset of the Ada language intended for formal verification of mission-critical software, is adopting safe pointers that were inspired by Rust (source: https://blog.adacore.com/using-pointers-in-spark).
I would not be surprised if Rust also adds features based on ideas from Ada.
This is good. The "fast and loose" qualities of C and C++ allow far too many errors and security vulnerabilities in software. We have better tools. We just need to use them.
Garbage collectors provide memory safety without any special syntax.
Or in Delphi all strings are reference counted. They are mutable, if the ref count is 1, and immutable when it is larger than one. It is memory safe with safe aliasing and needs no special syntax.
A sufficient smart compiler could just optimize the reference counting away, and treat everything as immutable, unless it can prove there is no aliasing. Ideally, a language would only have two kinds of reference, mutable and constant, and everything is figured out by the compiler
I guess Box<T> is special-typed but at the surface it just looks like a normal type
Yes, there's also a C pointer type, but it's for interop
But getting the C committee to act is about as hard as designing a new PL.
Now, also, will this new SaferC also bring with it any of the other features people appreciate in Rust? Such as data race free code (because of the strong type/trait system and Send/Sync auto types), or match and let statements that support destructuring of types through pattern matching, or monomorphism for zero overhead polymorphism, or the simple to use tools around the language for managing dependencies, or async programming model that strips away all the complexity of hand written state machines?
For me, all of those features make Rust a modern 2020 language. I’m curious what a SaferC would have. And frankly, if it could exist, why hasn’t it been developed in the last 50 years?
But, let’s say you’re right. D is SaferC—are the folks who are still waiting for a SaferC able to recognize it as such? Or, have they already decided that like Rust it doesn’t meet the criteria of the language that they’re waiting for?