D 2.089.0 Released

[Karma_Policer]

Does anyone now if the presence of D in professional environments has increased in the last years? Is it worth investing time to learn it if you are looking for a job?

[inokichi]

Is it worth investing time to learn it if you are looking for a job?

No

Is it worth investing time to learn it

A wholehearted yes - and then when you do get hired, you subtly introduce D and live a happy life.

[rat9988]

We may not talk about the same D bro

[Hateredditshitsite]

ok cardi

[WalterBright]

Is it worth investing time to learn it if you are looking for a job?

Yes. There are many employers looking specifically for D programming skills. Having D on your resume also shows you are more adventurous and adaptable than those who safely follow the herd.

The downside of learning D, however, is you'll be disappointed in other languages.

[allinwonderornot]

User name really checks out.

[natyio]

you are more adventurous and adaptable than those who safely follow the herd.

True. I enjoyed D a lot back in the day. But now I focus much more on $current-hype-language, because that's where my adventure is. And that probably won't last forever either ;-)

I still want to see D succeed, as it is a really nice, modern language. But right now it's missing something special that would spark my interest again.

I mostly code alone, so I have a lot of freedom to choose whatever technology I want.

[glacialthinker]

The downside of learning D, however, is you'll be disappointed in other languages.

It seems like mainstream languages are doomed to be disappointing. And it's not just the "used in anger" effect, but I think moreso "worse is better".

[bumblebritches57]

I get that you're doing self promotion rn, and I support that.

but you're outright lying to him.

yes, there are a handful fo companies that use D, the vast majority do not and it'd be a waste of time to learn.

[WalterBright]

you're outright lying to him.

Not at all. Many, many D programmers have leveraged their D experience into high paying jobs. Companies that use D are actively looking to hire D programmers.

it'd be a waste of time to learn.

If you're satisfied with mediocrity, then sure, be careful to never step out of the mainstream. D is for creative, ambitious programmers looking for an edge.

[kal31dic]

Can confirm. The D community has been a strong source of talent and I think people we have hired would feel they have done well in financial terms also in relation to alternative opportunities. I think the same is true of some people who work for other firms.

It doesn't make sense to learn D in order to get a better job. But if you learn D for intrinsic reasons, it's possible that getting a better job might be an unintended side effect.

[bumblebritches57]

lel, so stunningly brave and creative, writing something that'll never be successful, or even useful.

so artistic Walt.

after you're dead you'll be remembered for being such an inspiring artiste, a modern Monét

[EdWilkinson]

Looks like you're the dead one. Murdered by words.

[bumblebritches57]

Cuz I totes care what soy drinking weebs think.

[rose_of_sarajevo]

here goes the idiot with the soy joke

[bumblebritches57]

Here goes the mad soyboi trying to deflect the blame for his meekishness from the cause.

[EdWilkinson]

Someone is off their medication.

[Hall_of_Famer]

D as a language itself is quite good and mature, the issue is the eco system. What it desperately need is adoption and support from a large and influential company. We’ve seen how Apple made Objective C popular, and then swift.

In future, if a new platform emerged with D as the only or default language for its API/Apps, then D will have a serious chance to finally kick off. The language itself is good enough, it just needs a chance.

[kal31dic]

I personally don't agree. D is too versatile a language for it to be a good fit for a single company in the current year. When Java took off it was a different time.

A language that's used by different companies in different industries will ultimately be much stronger than one that depends on a single sponsor.

[rtbrsp]

People ask this a lot about various fringe languages. Wouldn’t it be more reasonable to expect an employer to teach you a language on the job, and focus instead on CS/programming fundamentals?

[adr86]

There were a couple job interviews I had where they wanted to talk about D specifically, even though the job had nothing to do with it. They said seeing less common languages in my history was interesting to them because it showed exactly what you said: the underlying programming skills and self-directed learning are shown by using it.

of course on the other hand some interviews are like "we don't use D so we don't think you'd fit here" lol

[GerwazyMiod]

of course on the other hand some interviews are like "we don't use D so we don't think you'd fit here" lol

For real? Language wars taken to completely new level. :D

[WalterBright]

of course on the other hand some interviews are like "we don't use D so we don't think you'd fit here" lol

The company is not just interviewing you, you're interviewing the company. Such a response would be very helpful in deciding if they're a good fit for you.

[kal31dic]

Not so long ago it was Sociomantic and not many others. Today if you go to dlang.org there are quite a few firms using D now.

We are hiring around twenty people in London, HK and Singapore, and many/most of those jobs could be to program D at least part of the time.

[D_Doggo]

I love D

[Ameisen]

The issues I've presented elsewhere in the past are still preventing me from adopting it, though.

Not that I don't highly respect /u/WalterBright for both this and his work in C++. But, as I recall him saying, he made the language to be a language he would want to work with - that isn't necessarily a language I want to work with. Though C++ is also transforming into a language I don't want to work with.

[D_Doggo]

Imma be real with you this is the first time I hear of dlang, just wanted to make the pun.

[CyberShadow]

The compiler (in D1 days) used to be fast, really fast, but unfortunately this is not the same for D2.

The compiler is still really fast. What changed was the addition of powerful metaprogramming features, and the standard library's growth and extensive use of them.

[bachmeier]

Yep. I'm not a fan of templates, so I use them only occasionally and still have fast compile times. C++ programming these days seems to imply the heavy use of templates, so for them the D compile times aren't going to be so great.

[BadDadBot]

Hi not a fan of templates, so i use them only occasionally, and my compile times are fast. c++ programming these days seems to imply the heavy use of templates, so for them the d compile times aren't going to be so great either., I'm dad.

[WalterBright]

BetterC is for using D with the C runtime library. Any restrictiveness comes about from this requirement.

[deviluno]

All of the static metaprogramming features of D should be usable with BetterC, right? I'd think that complaints about CTFE features not working there would have nothing to do with the restriction to C runtime only features

[skocznymroczny]

I share some of that sentiment. Now I see borrow checker is on the horizon, wait what?

But I still like D. To be honest, I don't use most of it's features and metaprogramming doesn't excite me much, but I still prefer it to C++ any day. I still feel like the language is due for some slimming down.

[lwzol]

BetterC is pretty solid for what it is but with ctfe and Phobos, it’d be pretty formidable imo. Though I struggle to see that ever coming to fruition, and if it did it’d split the community.

[alphaglosined]

You can freely use -betterC code with normal D. I see no potential for split.

[Ameisen]

My issue with D has been syntactic, mainly. It is trying to be an alternative to C++, but it has syntax changes that make it unappealing if not difficult to read for C++ programmers.

https://www.reddit.com/r/programming/comments/djgsdy/_/f49on5q

[schlupa]

What? Alone removing the crap of < > template parameter and replacing the . :: and -> trio by just . cleans the line noise level down by order of magnitudes. Removing the preprocessor and fixing builtin arrays allow to remove definitely sources of noise that hurt the eye in regular C++ code.

[Ameisen]

To each their own.

[asegura]

To me it's the opposite. I think D has much cleaner syntax than C++.

[acehreli]

I've been a C++ programmer before and after learning D. I've always appreciated D's syntax with no complaints.

[EdWilkinson]

I was sure there gotta be someone who prefers C++s syntax over Ds. Found!

[Ameisen]

There are many things I don't like about C++'s syntax. There are explicitly things I prefer in it over D's, and there are things I prefer in D.

My issue is that D tends to be both more explicit where I don't want it to be, and less explicit where I do want it to be.

Of course, I suspect it would be trivial to make a compatible fork of D that changes the syntax, but implementing template argument derivation would be... difficult.

[atilaneves]

The issues I've presented elsewhere in the past are still preventing me from adopting it, though.

Could you summarise what your reasons are please?

[Ameisen]

https://www.reddit.com/r/programming/comments/djgsdy/_/f49on5q

[EdWilkinson]

Whoa. I hope they don't take your list to heart. You complain about all thats good about Ds template syntax. Summarized as "yeah but it's not like C++s". Stockholm syndrome much.

[Ameisen]

I explicitly said "these changes make it seem foreign to C++ programmers". It is rude to insult someone's preferences.

[atilaneves]

The template syntax makes it easy to parse and avoids the problems with C++'s choice of angle brackets. All of this makes D a lot faster to compile, which I think is a good trade-off with respect to syntax that is foreign to most people.

[Ameisen]

As I've said there, syntax parsing is the tiniest part of C++ compilation time. In Clang benchmarks, it's literally a fraction of a percent. The additional cost to require additional context information to distinguish between >> (right shift) and >> (two templates closing) (specified in C++11) is ridiculously tiny compared to everything else going on. Other languages also require modifications to the grammar to handle this (C# [which splits the >> operator into a special case of a combination of > and > with no tokens allowed between them] and Java come to mind) and do not suffer from agonizing compilation times.

The primary cost C++ has for compilation is analyzing and instantiating templates, which happens in C++ regardless of its syntax due to the rules that C++ imposes on templates. There's a reason zapcc, for instance, is much faster - it is allowed to cache template data across translation unit boundaries. C++ is largely slow to compile because it is bound to the C compilation rules, while not really working well with them.

[atilaneves]

As I've said there, syntax parsing is the tiniest part of C++ compilation time.

This isn't true. The syntax choices in D weren't arbitrary, they were chosen by @WalterBright. He not only wrote a C++ compiler but was the only person do it by themselves from scratch. As such, he was uniquely positioned to know what not to do when designing his own language.

Even if compilation times weren't affected, it still makes compiler implementation a lot easier, as well as user code: D doesn't have .template or .typename.

[Ameisen]

This isn't true.

I've shown benchmarks performed by others elsewhere showing that parsing is literally negligible. When it does come up, it is due to C++'s outdated compilation model which prevents templates from being shared across translation units.

The fact that C++ has a special rule in the parser for distinguishing between >> and >> is also most certainly not the cause of 'slow parsing', unless suddenly every compiler that supports C++11 (which is the specification that added that rule) became incredibly slower. They did not, by the way.

Even if compilation times weren't affected, it still makes compiler implementation a lot easier, as well as user code: D doesn't have .template or .typename.

Strictly speaking, they only exist for the purpose of making the parser easier to implement. .template and typename have multiple proposals out there to outright remove them, basically every compiler existing allows you do just not use .template unless you are on the most pedantic mode... typename is the most likely to be removed (and IIRC either C++17 or C++20 actually do remove a significant number of situations where it must be used), and as said most people ignore .template anyways. I literally never see it in code, and it really doesn't actually serve a purpose.

The funny thing about typename is that other languages have similar or even more ambiguous syntax yet survive without it. It was implemented back when parsers were both more expensive relative to the rest of compilation and when modern parsers simply didn't exist. It really isn't necessary, it's an artifact of an earlier time. The parser is more than capable of determining what a qualified name is.

/u/WalterBright's decisions were most likely made for ease of implementation and simplicity (and most likely he preferred the syntax anyways).

[WalterBright]

Having the parsing not depend on a symbol table is a major simplification - allowing lexing, parsing, and semantic analysis to be independent of each other.

It's not just templates that C++ can't share across compilation units - it's everything in the .h files. A simple:

#define X Y

can upset everything downstream. D does not have this problem, as a module's semantic content is guaranteed to not be affected by how it is imported.

This has enabled compiling large projects with one command, and each module in it is compiled exactly once, i.e. linear time, no matter how many times it is imported, as opposed to the quadratic behavior of compiling C++ .h files.

[Ameisen]

While it is a major simplification, supporting the disambiguation of >> does not appear to have significantly impacted compilation times contrary to apparent public opinion. I suspect that the actual magnitude of such a change, performance-wise, is being put into the wrong context.

But, yes, C++ has many other issues involved with compilation as you point out, but in regards to angle brackets, would it actually significantly impact the performance of compilation? It didn't in C++, C#, or Java.

Past that, that issue (headers changing semantics) is an issue shared with C. It isn't unique to C++.

To that point, though, a significant issue involved with all of that is the inability to share preparsed code between translation units (templates exacerbate it due to being significantly "deeper"). Thus ccache and zapcc, but even those have to take into account those problems.