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?

>>55
It's not purported to be safe!
Oh, well that makes more sense then. Somehow you had given me the impression that the annotations were something other than manual memory management.

I don't care if it's provably safe; I will reason about whether it is correct myself.
One moment you're going on about the inherent unsafety of manual memory management--which isn't always true, or even meaningful¹--the next you're saying you don't care. I take it there is more to your point which is deep between the lines, but I just can't find it. 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.

[...] Halting problem.
As I mentioned above, you'd given me the impression that the annotations were something other than equivalent to manual management. Anyway this 'halting problem' thing was cute the first time, but you don't need to repeat it constantly like you just heard about it last week. I'm not trying to shit on you, I just haven't been impressed by anyone making ineloquent equivalences to the halting problem in a very long time.

There is certainly provably safe memory management in restricted subsets of the language.
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.

I'm very sorry if I'm ignorant of Go's exceptions, but they did announce the feature a whole twelve days ago.
I don't care that you don't know, but I do care that you don't know and yet try to speak authoritatively on the subject.

It was part of the language from very early on. The announcement isn't an announcement, it's something they figured interesting enough to blog about--almost everything on the Go blog has been around within a month of the initial language announcement. IIRC, defer() has been in since day 1 and panic/recover were discussed and implemented shortly after.

On semantics, since you don't have much interest in Go I don't want to get into the similarities and differences between its defer/panic/recover stuff and whatever language's model you happen to be thinking of at any given time. Semantics aside, the syntactical advantage is huge in my opinion--which is all I was trying to point out when you went after me on semantics. Not cool.