I am in my learning curve for D as an experienced developer.
What has attracted me to D is the combination of features:
Design by Contract, Functional Programming, OOP, and more.

But I have been exploring the "weeds" and am curious if D is only for rocket scientists or for regular programmers, including as a first programming language.

It would be good to have a "style" document that showed the "best practices" and "Do's and Don'ts" of good D programming.

Every language has its "nits", even Eiffel. The concern is whether that is a straight forward approach to get things done, avoid the "dragons", and work with existing libraries without needing a "wizard" to cast some spells.

Should D be considered a language that should be learned in its entirety?
Or should most developers stick to the "Safe D" subset?

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

"D the good parts", syntax should be learned in a few hours: https://github.com/crazymonkyyy/dingbats

Id probably delete over half of programming in d's chapters for beginner introductions. Im confused by the order.

The true depths of template hell, is still unlearned by anyone; there are bugs that provide more capability then what upstream release is a few years that were undiscovered for 10 years, just there in how it was implemented.

Wrong boundary, its template hell vs c-like d

Safe D will bring in complexity, those dips make problems hard to solve, "how do I write swap thats @safe from dip 1000 1069 1337?" well thats an on going research project last I saw was 100 lines of code with criticisms about 5 edge cases, id just go with the 4 lines of code.

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

I think what you should get is that D is a language that "clicks". That means that you have previous experience with other languages. They can be more complex than D but also sometimes less complex. So often that just "clicks".

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

This is both one of the strong and weak points of D: It gives you a ton of flexibility and lets you model code in a fairly free-form way, unlike languages like Go where variety between codebases is very minimalised.

There's things like The D Style guide (https://dlang.org/dstyle.html) which is used for Phobos, and there's the slightly crusty D Idioms list (https://p0nce.github.io/d-idioms/) going over a bunch of misc stuff.

I initially had more to say, but monkyyy's answer kind of eludes to it - there's many different ways to use D (half baked or not) to the point nothing can truly work together in exact harmony.

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

D is invested in letting you program how you want, it is designed to allow many different programming styles to co-exist. You can go full C procedural style, or opt for a more functional style, or use OO, or any combination of the three. None of these ways is wrong or right.
My only word of advice is to consider using structs over classes when passing around small amounts of data. A lot of D newbies use classes for everything and ignore structs as if they don't exist. Also check out std.sumtype if you ever need tagged unions. It's really useful for a lot of stuff!

For fun, yes. But if you get started and learn as you go then you'll probably pick up the vast majority of it. And the stuff you don't learn is probably not important to you. For example, if you use OO a lot then you will probably barely touch D's incredibly rich (and complex!) meta-programming.
Things I recommend familiarising yourself with are:

• the range interface & what ranges are (front, popFront, empty)
• how strings work in D (they're arrays of immutable char, where char is a UTF-8 code unit—not to be confused with a UTF-8 code point)
• what slices are (AKA 'dynamic arrays') and how/when mutating GC-allocated slices causes them to be re-allocated
• other things you need to know to get your work done. If you need to process data, like splitting by comma, sorting, etc. then get familiar with std.algorithm. If your work requires lots of maths then get familiar with std.math.
• a lot of Phobos functions are named a bit oddly, so sometimes you have to rummage a little to find what you want, or you might not realise that it's there.

If you are doing web development, yes.
If you are a low-level systems programmer or game developer, then try to use @safe on as much of your code as possible, but you will be calling @system functions in a lot of places to get your job done. (e.g. kernel, SDL, etc.) I recommend checking out the new -preview=safer as well if this interests you. And remember: if you misuse @trusted, then @safe will not save you.

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

I think everything is ok as long as you keep it simple.

On Tuesday, 5 August 2025 at 12:32:53 UTC, Brother Bill wrote:

After little bit over 20 years of using D I believe I learned/used 60% of language features. - There are lots of things I either do not need, or do not like, that I do not use. Language is a tool, right - you use it the way you prefer to use it. My intention was never to become a D language expert. I just want to implement my next planned feature of my D application in a way that suits me.

That is why always my recommendation for developers who are using new language is - think of something "you need", and implement that in this language. As long as you progress you will learn those language features that you need, and that is all that matters.