>>36
C++0x doesn't have GC
That's why I said the standard *AFTER* C++0x. It will have GC, and will also have things like proper module support (so we can finally get rid of header files), scoped macros (which will probably end up extremely similar to mixins from D), and more. I am telling you, these two languages are converging. In ten years they will be semantically nearly identical. (I also think this is why D will never gain any traction; its useful features will just be added to C++, and people will put up with C++'s warts for compatibility with existing libraries.)
>>35
The optimist would point out that they're researching a new collector, based on an existing collector which is covered by patents.
I'll believe it when I see it. Maybe I'm too pessimistic, but Go has already made enough horrible design decisions to make me extremely skeptical of such promises.
It's no worse than the thread's premise: bitch about C++. [...] I challenge you to present a suitable replacement systems language, or a description thereof. Anything else is just complaining that C or C++ sucks
That's not what this thread is about at all. I'm not here to point out C++'s faults; the very first sentence in this thread shows that I'm going on the assumption that we already all know its faults.
This thread is about why no one cares to replace it. Essentially no language research is being done in this field. The only language I know of that even attempts at being a replacement is D (we've already established that Go is a lie), but D does not solve C++'s biggest problems, such as verbosity and development speed. D is just a band-aid; it's far too similar to C++.
I challenge you to present a suitable replacement systems language, or a description thereof
Again, this isn't really what this thread is about, but I'll try to talk a bit about what features I would like.
First off, I would think a replacement language could start with full type inference. I would like to just leave out types entirely, with code looking something like JavaScript. Type annotations could be added where desired with a simple predicate, like @int. That alone would be the biggest step towards cleaning up some of this verbosity and development speed. While we're at it, I'd like implicit type parametrization. I shouldn't have to declare that something is a template. If I leave off type annotations, it's a template. I could also do with struct and enum inference. I'll just declare a struct and leave it empty; treat it as a hashtable in the meantime. Python does this: you use fields on an object as needed, and when you want to make it fast, you declare slots.
Next, the language should make references more implicit. A lot of time in C/C++ is spent dealing with addresses, pointers, references, etc. Just look at how thick C++ code is with ampersands and asterisks. This could be automated in an obvious fashion, but still available when I need to override the obvious defaults. I think C# does this well: you have value types and object types which behave in a straightforward manner, but the ref keyword lets you make references of value types when needed.
It should also make things like RAII simpler and more obvious. I shouldn't need to write a destructor for *anything* unless I need to close a system resource, like a file handle or socket; instead I should just annotate which pointers are "smart pointers", i.e. owned and freed via RAII, and the compiler fills everything in. C++ can sort of fill it in for you if you use only smart pointers everywhere, but smart pointer syntax is horrible, and it has problems such as automatically inlining implicit destructors. That's very bad. I don't really know to what extent D can solve this, but I see a whole lot of destructors in D code.
I would like garbage collection to be used as the default, and once in the optimization stages, 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. D is the only language I've ever heard of that attempts this: you declare variables with the scope keyword and the memory lives there, instantly RAII. This is somewhat limited however; there aren't smart pointers, so it has to be a stack or field allocation to be RAII.
I'd like a much more powerful type system for proving things at compile time. For instance, why the FUCK do all these languages still have null pointers? They should not have null at all; instead, they should have tagged unions. If you want a variable to possibly be null, you make it a tagged union with the null type; the compiler then forces you to check for null wherever you dereference it. There is no overhead for this; it compiles to the same damn machine code, so there is no reason not to do this. Why can't I statically prove other things about code, like that memory is never leaked? This could be done easily in C++ for example if new returned a unique_ptr<>, and did not ever let you reset a unique_ptr<> or create one from a raw pointer. All pointers would then be trapped inside exactly one unique_ptr<>, forcing them to be cleaned up. These are about the simplest possible improvements to the type system; you can go a whole lot farther than this.
When I compare my productivity and code quality between developing in Python and C++, these are the most obvious issues that cause such a massive discrepancy. I'm sure I could think of more.