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?

>>59
I'm trying really hard to keep up the perception that you are not just trying to posture D above the rest but by now I have to admit that doubt is casting a very long shadow over the affair.
Hardly. I've mentioned D often because it's the only major attempt at replacing C++ in embedded and game development (there are a few toy languages out there, but they are still experimental at this stage). I actually hate D, mostly because it's even more complicated than C++. It does not make development any easier or better; it just gives you slightly less chance of shooting yourself in the foot with some obscure C++ gotcha.

Your examples are quite limited and don't cover even what naive static analysis can accomplish. I was also thinking specifically of heap allocations--stack allocations limited to non-escaping references don't need any management, they live and die quite organically with program flow. So really you're not really talking about manual memory management at all.
True enough. Compilers like Stalin, or JIT compilers like the JVM can eliminate many (even most) allocations through the kind of static analysis you're talking about. The point is that it's simply not possible to handle all allocations in general. All of these use a garbage collector as a backup strategy. You seem to be ignoring this rather major issue, which is why I keep mentioning the halting problem. If it isn't possible to do all of them, then it's rather useless for embedded, isn't it? Even a handful of garbage collected objects mean you have to scan the whole heap, so you still have most of the downsides of a garbage collector.

I think we've pretty much come to a point where we agree on most things now (except for interest in Go, heh.) I can't help but feel disappointed in this thread. Not the posts or posters; more in the general outcome. We just ended up quibbling over minor issues in different languages. I don't know what I expected. Bleh.