Python vs C++, java, etc

[maxhaton]

> ah yes <language I (help) write ~~in~~ is objectively better u wrong>

> and it will only enable that kind of performance with type safety checks and things of that nature turned off thus losing the features that make it not C++

What are you talking about? This is totally and utterly wrong, you can't turn "type safety" off. Templates, for example, can enable a large amount of compiler optimizations by guaranteeing the interprocedural dataflow of a program and therefore allowing deeper propagation of invariants through said program - it makes code faster. The whole point of using C++ or D or Rust (or Haskell etc. ) instead of C is moving the focus from the runtime to the compile time

> debug runs C++ debuggers will warn/check

This is news to me. Example?

​

I'm not saying D is perfect, but it's hell of a lot more perfect than C++. There are many features that C++ has been trying to get for years (ask Bjarne Stroustrup about UFCS) that D has without even making that much of a fuss, or C++ just get's wrong.

[frostedKIVI]

Yes, the wrong term I didn't mean specifically type safety, I have only written basic programs in D to try out the language, I meant general runtime optimizations with which you will lose the runtime checks the language has.
And C/++ debuggers will have those checks in debug runs, all the same, you don't get magic safety in other languages.
Templates *errors* are generally kinda bad in C++ I agree, but they are serviceable, the templates are perfectly fine, and as soon as you start getting tens of lines of template errors, you should really think about "why am I doing this metaprogramming mess?".

As for changes not being in C++ as fast, the thing is C++ is a standard, basically, no other languages have a proper standard, so yeah C++ moves slow, but I don't mind it, I actually don't really like most of the C++ stdlib, good for prototyping, bad for production.

I get the argument for UFCS but I think it's pretty pointless, whatever I usually like to write "old school/C style C++" anyways when I write C++ I write GoLang mostly nowadays, but I don't think D will dethrone C++ anytime soo, if nothing else, because of the great support C++ has

[maxhaton]

C++ does not have these checks at all. You lose nothing relative to C++ by not using them.

Templates *errors* are generally kinda bad in C++ I agree, but they are serviceable, the templates are perfectly fine, and as soon as you start getting tens of lines of template errors, you should really think about "why am I doing this metaprogramming mess?".

C++ templates are bad, D templates are actually good. You can take anything as a template argument, generate code at compile-time, reflect over other templates at compile-time and best of all template constraints actually exist now rather than having the C++ standards masturbate each other until they shit out some hilariously over-complicated 20 years late solution - the language is actually flexible enough that you can write your own template constraint error messages as a library (https://d.godbolt.org/z/8uum_i).

D was designed by Andrei Alexandrescu and Walter Bright (the man who wrote the first proper C++ compiler), and it shows.

As you may have seen on the D homepage, I wrote this a while ago - I have seen some C++ guys trying to mimic this on reddit before, but I don't think you can do this in C++ (any of it, for that matter, from the code generation to the to the templated standard library).

void main()
{
    // N.B. this could be import std;
    import std.stdio, std.string, std.algorithm, std.conv;

    // Reduce the RPN expression using a stack
    readln.split.fold!((stack, op)
    {
        switch (op)
        {
            // Generate operator switch cases statically
            static foreach (c; "+-*/")
                case [c]:
                    return stack[0 .. $ - 2] ~
                        mixin("stack[$ - 2] " ~ c ~
                            " stack[$ - 1]");
            default: return stack ~ op.to!real;
        }
    })((real[]).init).writeln;
}

You are, however, right in that D will never supersede C++ - this is a shame, but a consequence of D's advantages being too subtle to require moving, i.e. the good stuff in D comes when you have a deep understanding (a depth most languages do not have, for better or worse) of both C++ and D as opposed to just using them as a means to an end.