GCC 9.1 Released As Huge Compiler Update With D Language, Zen 2, OpenMP 5, C++2A, C2X

[sdack]

new - adjective, new·er, new·est. ...

You could have said that anything older than a second is not further new, and your opinion still would not matter.

[Ironmask]

People create new languages everyday, in companies, at universities, in basements, but these are meaningless for most users. It takes a long time for a free and universal programming language to gain hold. 10-20 years is a short time. Even for a language standard to establish itself can it take 5 years. Many languages in use today, which we consider as fundamental programming languages, predate 2000. In this context is D a new language. I wasn't referring to the "last autumn collection of fashionable programming languages for the completely uninformed programmer" when I said D was new.

new - adjective, new·er, new·est.
1. of recent origin, production, purchase, etc.; having but lately come or been brought into being: a new book.
2. of a kind now existing or appearing for the first time; novel: a new concept of the universe.
3. having but lately or but now come into knowledge:

I don't see "not popular yet" in the definition of the word "new". Rust caught on almost instantly. D is 20 years old, it isn't new in any sense of the word, and inventing definitions to fit some abstract concept of not being widely used isn't valid.
I'm not sure why you keep pushing this point or continue to passive-aggressively taunt posters by insisting we're some naive college kids who haven't touched anything besides Python just because we disagree with your unacceptable, droll definitions of words. D didn't catch on, it probably will never catch on, it still won't be any newer than it is now 100 years from now regardless if it does catch on or not. Let it go, it still has a healthy community if you love it that much, it's just that it isn't interesting enough to use for most people, especially now that we have Rust and .NET Core. Insisting D is "new" and anyone who disagrees is [passive-aggressive moniker meant to imply naivity] won't make D any more of an industry standard than it is now.

[sdack]

The world has changed. ...

No... Besides, what an idiotic thing to say that "the world has changed"?!

It's because of change that people keep looking for what remains constant and so it can be trusted to be a constant. It's why some still program in C, Fortran or Perl, and why others desperately keep changing everything. People choose languages often not for their technical merits. They choose them because they want to have it on their CV, because it attracts a certain type of programmer, because it's dominant for the market they are in, or they choose it because they have no other choice, or because somebody told them to.

It's not because "the world has changed".

[caligula]

People create new languages everyday, in companies, at universities, in basements, but these are meaningless for most users. It takes a long time for a free and universal programming language to gain hold. 10-20 years is a short time. Even for a language standard to establish itself can it take 5 years. Many languages in use today, which we consider as fundamental programming languages, predate 2000. In this context is D a new language. I wasn't referring to the "last autumn collection of fashionable programming languages for the completely uninformed programmer" when I said D was new.

The world has changed. Probably the most popular web technology stack is only 5 years old: https://en.wikipedia.org/wiki/React_(JavaScript_library)

Git was also pretty new (it's 14 yo now) when people started migrating from other DVCS solutions such as bzr, mercurial, monotone, arch, bitkeeper, darcs.

[sdack]

The original fan base of D 1.x (DMD 0.xxx back then) was forming already in the early 2000s. Some of those users created dsource, gdc, the tango runtime, and so on. The current D 2.x was discussed more than 10 years ago and there was even a conference where they discussed the version 2. I didn't use the language, but remember considering it as a promising new alternative to C/C++. What I recall is, almost all D programmers were waiting and waiting and waiting for a more stable compiler. So.. D can be seen as new now if you also think that C was new back in the day when the ANSI C = C89 standard first appeared.

People create new languages everyday, in companies, at universities, in basements, but these are meaningless for most users. It takes a long time for a free and universal programming language to gain hold. 10-20 years is a short time. Even for a language standard to establish itself can it take 5 years. Many languages in use today, which we consider as fundamental programming languages, predate 2000. In this context is D a new language. I wasn't referring to the "last autumn collection of fashionable programming languages for the completely uninformed programmer" when I said D was new.

[caligula]

No, it is. Only for a person with a short attention span may it seem ancient.

I'm not surprised to now see Rust and C# being mentioned here.

The original fan base of D 1.x (DMD 0.xxx back then) was forming already in the early 2000s. Some of those users created dsource, gdc, the tango runtime, and so on. The current D 2.x was discussed more than 10 years ago and there was even a conference where they discussed the version 2. I didn't use the language, but remember considering it as a promising new alternative to C/C++. What I recall is, almost all D programmers were waiting and waiting and waiting for a more stable compiler. So.. D can be seen as new now if you also think that C was new back in the day when the ANSI C = C89 standard first appeared.

[discordian]

Typical example of what I call the C++ Stockholm Syndrome. Any modern C++ compiler will for example accept the following code:

unique_ptr<foo> bar(foo& f)
{
return unique_ptr<foo>(&f);
}

...
auto f = unique_ptr<foo>(new foo());
auto f2 = bar(*f);

And presto! Two or more supposedly unique pointers now refer to the same object. And while this example is caricatural, it goes to show that if such things are possible while strictly adhering to the standard, then none of the problems have been SOLVED, just wrapped and kicked under the carpet. There is nothing inherently "powerful" about a language like this, it's just an irremediable trainwreck. A good programmer, in my opinion, is one who understands this, not one who insists that he wants to fly a cardboard plane whose wings fall off at any time, who claims that in some cases it is possible that it may not crash and that a good pilot can fly any old piece of junk.

And guess what language is used for aviation, the trick is that the standard just frankly is not enough, you need some strict guidelines for strict guarantees like AUTOSAR C++ or MISRA.
The culprit here is that C++ aimst to stay compatible. If you would want to write leakfree code, then you would define rules for passing owning pointers,
and might forbid passing references / raw pointers in favor of using smarter classes.

The bottom line is that what I'm interested in is code provability and a language like Rust goes a long way, although not completely and not perfectly, towards being able to mathematically PROVE, not claim, that your program's memory management is sound. That's part of what I consider the signature of a Good Programmer, as opposed to a L33t "Real Programmer Who Knows What He's Doing" (but doesn't really).

That's only a small part of the problem, it doesn't help if your pointers are still reachable for the program if they are effectively "dangling" on a pointer you will only ever free upon termination.
On safety critical software you wont use global heaps but small tables of pre-allocated memory, C++ further allows you write classes and even containers (of fixed max capacity) that live perfectly on the stack. You only use global storage if absolutely necessary, at the latest point (after all checks) as that eases up cleanup and verification alot.

Don't get me wrong. There ARE valid reasons to select C++. There is a wealth of libraries and frameworks for it that Rust doesn't come even close to. Debugging tools, profilers, benchmarks etc. are way more mature than what is available for Rust. There are many competing C++ compilers, Rust has only one non-toy compiler. C++ can be used on many more CPU architectures and target platforms than Rust. Etc etc etc. But its flaws are real and while you can decide to accept them as a price to pay for some of its other benefits as above, they don't make it a powertool as you say. It's still just a crappy tool that a skilled professional should recognise as such.

Pretty much all those flaws can be attributed to its legacy, with strict rules and tools that will make you abide to those rules you can get all the advantages from Rust, and you have all the tools for formal verification (that's your mathematical proof, but this is done at design/algorithm level and not at the implementation) and quality assurance that Rust lacks.
Its still the only valid tool for anything safety, paired with strict guidelines. If rust will ever be included in that list, you can be sure it wont be the "rust standard" but a restricted subset defined by a guideline.

[sdack]

Seems your problem is not being a good enough C++ programmer.

Your notion seems to rely on "C++ programmer", but it's also a problem. A programmer (of any language) needs to get a job done. If one first has to become a "good C++ programmer" then it hides the fact that C++ is a complex language to program in. Most people believe that tools are meant to serve them and not that they have to serve the tools, and wasting an enormous amount of time for using one particular language isn't attractive.

The more complex a programming language is the worse it is to maintain code written in it, because there will always be some who program badly, who use features incorrectly or excessively. This is probably the number one reason why C++ hasn't reached the popularity of C and why people look towards other languages instead. People want to achieve more, while doing less for it.

[sdack]

But I'm pretty sure you're a troll judging from your previous comments so I'll digress.

No, you are and I'm sure you understand what I wrote about and only don't want to back off, but maintain your course of insult and pettiness, because you don't know any better, which makes you the troll but not me.

And should I ask?! What actually do you mean by "C# being an evil version of Fortran"?

[jacob]

Seems your problem is not being a good enough C++ programmer. The problem with powertools is not that you can hurt yourself on them and the problem with planes is not that a pilot can fly it into the ground if they steer it downwards.

Typical example of what I call the C++ Stockholm Syndrome. Any modern C++ compiler will for example accept the following code:

unique_ptr<foo> bar(foo& f)
{
    return unique_ptr<foo>(&f);
}

...
auto f = unique_ptr<foo>(new foo());
auto f2 = bar(*f);

And presto! Two or more supposedly unique pointers now refer to the same object. And while this example is caricatural, it goes to show that if such things are possible while strictly adhering to the standard, then none of the problems have been SOLVED, just wrapped and kicked under the carpet. There is nothing inherently "powerful" about a language like this, it's just an irremediable trainwreck. A good programmer, in my opinion, is one who understands this, not one who insists that he wants to fly a cardboard plane whose wings fall off at any time, who claims that in some cases it is possible that it may not crash and that a good pilot can fly any old piece of junk.

The bottom line is that what I'm interested in is code provability and a language like Rust goes a long way, although not completely and not perfectly, towards being able to mathematically PROVE, not claim, that your program's memory management is sound. That's part of what I consider the signature of a Good Programmer, as opposed to a L33t "Real Programmer Who Knows What He's Doing" (but doesn't really).

Don't get me wrong. There ARE valid reasons to select C++. There is a wealth of libraries and frameworks for it that Rust doesn't come even close to. Debugging tools, profilers, benchmarks etc. are way more mature than what is available for Rust. There are many competing C++ compilers, Rust has only one non-toy compiler. C++ can be used on many more CPU architectures and target platforms than Rust. Etc etc etc. But its flaws are real and while you can decide to accept them as a price to pay for some of its other benefits as above, they don't make it a powertool as you say. It's still just a crappy tool that a skilled professional should recognise as such.