Seems to be a similiar problem field as writing blocking functions that call async functions in C# and co-existence of synchronous and asynchronous code.
> why people literally do not and cannot get it right 100% of the time. Thinking so is pure hubris.
Sure we all don't get it right 100% on the first write. For this reason we test and iterate. Equally you could say that it is pure hubris that a language will enable you to make your code right 100% of the time.
You mean the vector::operator[] is an example of fast-and-potentially-UB ? I don't see any UB if the constraints are met (keeping the index within valid range).
If they are not willing in a specific case they for sure had specific reasons not to be.
I think it would be more constructive to propose a constrained subset, get rid of legacy, propose default behaviours for parts that are undefined and so on. Stuff that does not belong to this subset can still be used within an unconstrained clause.
If I read e.g. "Why build Carbon?" on https://github.com/carbon-language/carbon-lang I dont find any concrete reasons or proves that show why C++ should be abandoned for something completely new but somehow very similar. There are so many question around the actual language definition like who maintains it, how is the standardization process. Who will adapt to it or to something else. ... This seems all so utopic.
I have been using C++ for many years with fantastic success. It allows me to create all I want/need from embedded to high performance projects.
That you may shot you in the foot is in fact not bad. It compels you to be careful and think deeply about the design and only use what you completely understand.
With other languages your program might not crash but probably will do wrong things like eat up memory or access still references outdated data. You will find error much later in the process when it costs multiple magnitudes more.
Syntax is mostly a matter of taste. Preference of taste and style changes with time and trends. Why should "let name : type" be preferred to "type name"? Just because others do it? Why and this unnecessary, additional ':'?
> C++ has this issue of every few years looking entirely different
So what. The style you have been using does the job then just keep it. There is no obligation switch to use new stuff. You should stick with that what proved to be successful.
> I mean, the almost-simplest abstraction possible the std::vector has potential UB right in its [] operator.
It's your responsibility to pass the allowed range of value to a function. It a function description tells you to e.g. pass only non-null pointers or only even integers then it's your fault if you don't do it. Inside the function there may me asserts but there is no need to such checks in general.
> There's just sooooo much that you have to get 100% right as a programmer
It's simply the job of the programmer to get it 100% right. No language can do this job for you.
having segfault is the best you can have: it tells you explicitly that something is wrong with your program. in other languages the same kind of error may result in stale data and the GC does not collect the data and the memory consumption grows slowly. You will notice the problem much later.
Np language can solve the inability of writing a correct program. Do you believe if your Rust program compiles it is free of errors??
After your battle with the compiler is over and it compiles it does not mean your program is correct! If you now what you you have no issues with C++. It's not the language. It's the design, approach and attitude
The typical, well known blog pattern for writing against C++: Show some buggy code an then conclude that C++ is wrong. Instead of asking: Who is wrong, the programmer trying to speak the language or the language itself? As always: Only use what you understand how it works. Instead of directly escalating it to cardinal questions of language superiority he had better used his time constructively and wrote a tutorial on how to correctly use things like string_view and span, that are a typed reference to memory that exceed the live time of the string_view.
There are numerous recommendations such as
https://learn.microsoft.com/en-us/archive/msdn-magazine/2015...
Final phase is "I hope these techniques will help you adopt async into your existing applications in a way that works best for you."