Programming Language to Replace C++

I think we can all agree that C++ is a terrible language. So why is it still around?

When talking to most C++ users (game developers, systems programmers), I've found that most seem to recognize C++'s faults, but they don't really care. They aren't even the slightest bit interested in a new language that might solve its problems, even one that gives them all the power of C++ with none of the downsides. You can't even get them to look at something new.

Why is that? Why does everyone just 'live with it' without wanting to improve the situation?

>>38
I'll believe it when I see it. Maybe I'm too pessimistic, ...
Oh I don't blame you. I think they still intend to make good on that, and I believe it's completely possible for them to do so. I don't have perfect faith that they will actually see it though though.

That's not what this thread is about at all. I'm not here to point out C++'s faults;
Yes, but about the road to hell, again:
I challenge you to present a suitable replacement systems language, or a description thereof. Anything else is just complaining that C or C++ sucks
In a vacuum you'll only get the complaints. Barring some very light commenting on C++0x (not a great start), Go is the only thing discussed that hasn't already been done to death.

full type inference
implicit type parametrization
Have you looked at Clay? http://tachyon.in/clay/ I wish I knew more about it, but there are (still) no docs yet. The tagline is Efficient, concise, generic - Pick any three. Doesn't look half bad considering.

the language should make references more implicit
I disagree here. I will admit to being very C-minded and this is probably a symptom of that. If you already have by-ref and by-value types then it's no big deal, but switching over to that model for no other reason is probably not great. I'll pretend you said something about safety and I'll drop it, deal?

I'd like to be able to transform a GC'd program into a manually managed program just by reasoning about object lifetimes and adding appropriate type annotations
I'm not clear on this. Do you mean the compiler should perform analysis and insert malloc/free or equivalent calls in your code automatically?

About null pointers, I'm not quite convinced on the performance comment. If you can prove certain things you can eliminate the need to perform checks in certain cases, however. This is typical in manually checked pointers (where 'proof' is on account of "I'm the programmer and I reckon it"), but if you want to meet that with automatically checked pointers, you need to prove it automatically. Again: safety. Then again: systems.

Why can't I statically prove other things about code, like that memory is never leaked? ...
That's a tall order. Your solution doesn't add up to me: doesn't that work at run time and require a trace? How would that be done statically when the problem is non-deterministic in many (most?) running programs?