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?

>>29
It is also intended to replace Python in-house
[citation needed]. I call bullshit on this, for a lot of reasons, but probably the most important is that Go is a whole lot less powerful and more limited than Python. It is not suitable as a replacement. If they want something as powerful they need a dialect of Lisp, or Ruby, or a standalone JavaScript, or something. They could have just pulled V8 out of the browser, scrapped the shitty API, and started with that instead.

Another big reason is that there is absolutely no point to switching away from Python. If they are trying to make it fast, they could just switch to a different interpreter like PyPy, or write their own from scratch. If they really want micro-threading, why wouldn't they just switch to Stackless?

The reason they have not done this is because they have a massive volume of C code locked into CPython's ABI. This is why they are trying so hard to make CPython fast with Unladen Swallow (the most underachieving optimization project in history.)

>>28
you might want to refresh your knowledge of modern GC implementation techniques.
This is almost certainly true; I stopped caring about it a while ago because Java is just as bad as the JVM is good. The JVM is also (currently) ill-equipped for the dynamic languages that are being built on it, like Clojure or Jython. Seemed like a whole lot of wasted effort.

Another approach would be to follow C#, which also provides raw pointers, but to obtain a pointer to a managed object you must use the ``fixed'' construct which makes the object temporarily pinned, and also is lexically scoped which prevents leaking pinned memory.
That would be the ideal way to do it. Unfortunately, unless they want to make a major backwards-incompatible change, it's too late to do this.

I'm still not convinced that it's even possible to make a copying collector for Go. It just allows too much unsafe shit. Even if you could, the developers have *zero* interest in doing it; they just say "we hope to have a fast collector someday", as though they expect it to magically pop out of the ether. The current collector does not even retain object layout information, so it can mistake regular ints for pointers and improperly retain memory. Boehm's has built-in facilities to supply layout information! Why are they not using it!?

Bleh. I did not want to derail this thread into a discussion about Go.