OO support is more than just record.method(), which is something you don't even have in OOP systems based in multi-dispatch.

Reminds me of vim script's implicit method syntax [1]

Eg. any function call can be converted to a method call on the function's first parameter:

    let mylist = [3, 2, 1]
    " prints "1" as these two are equivalent
    echo sort(mylist) == mylist->sort()

Helps a lot with chaining.

Dot syntax tends to work better for code completion, though.

In addition, without uniform call syntax, adding a new method can only break subclasses, whereas with uniform call syntax it can break other client code.

    int addOne(int v){
        return v+1;
    }

    int foo=3;
    writeln(foo.addOne);

I was about to say "Yeah, its my favourite feature of Nim!" and then I realised what account I was replying to ;)

> When you have UFCS you can toss out 90% of the uses of methods in favor of just plain ole functions.

Can those go away if you use inheritance or polymorphism, and you need your functions to access protected or private members? I mean, OO is as much about methods as functional programming is about functions.

If all you're doing is accessing public members, sure.

> It's a mystery why D isn't far more popular than it is.

There's no mystery. It's a jack of all trades, master of none. E.g., the virality of the GC makes it a non-starter for its primary audience (C/C++ developers). The need to compile and the extra verbosity makes it a bad substitute for scripting like Python. Etc.

Basically, name any large niche you'd expect it to fill and you'll probably find there's a tool already better suited for that niche.

We don't have a marketing budget, although we have many hard core users!

  // Sort lines
  import std.stdio;
  import std.array;
  import std.algorithm;

  void main()
  {
      stdin
          .byLine(KeepTerminator.yes)
          .uniq
          .map!(a => a.idup)
          .array
          .sort
          .copy(stdout.lockingTextWriter());

I needs a "Django", "Rails", "ASP .NET" type of project that is out of the box ready. Go has net/http out of the box. I think if D had either a batteries included (Vibe.d is nice, but you have to handle some things still) web framework, it might convince some folk to use it more.

Go spread the way it did because it was dead simple to make websites and services, the syntax is insanely simple, but the language allows you to scale without going through a ton of hoops. Look at how much of our IT infrastructure is powered by Go now.

D has a lot of potential, but someone has to sit down and build frameworks and tooling for D.

I think if D had officially supported libraries by core maintainers that take full advantage of the best of D it might be a different landscape.

Another area where D could shine is GUIs. Everything is electron these days, it feels like nobody builds usable GUI stacks. If D had an official solution to this, and it worked nicely and gave you enough power to customize your UI, we might see a shift there too. I welcome a Electron free future.

Look at the Zed editor (ignore the AI buzz) and how insanely fast it is. Its coded in Rust, and uses WGPU iirc to just render everything kind of like a video game, but it runs insanely fast. It is my new favorite text editor.

Sadly despite my deep love of D, Go is where I'm leaning more towards, due to industry pull there.

I spent quite a few year on/with it back in the day. There was D1 which was like a better C, and then there was D2 which was like a better C++. Personally I preferred where D1 was going (and Tango instead of Phobos) but even with D2 it really made the day compared to what was out there and to this day still to an extent is. The thing that killed it for me, and I know at least a couple of friends as well (outside of internal politics at a time) was what kills pretty much all exotics once you start using it. Lack of (up-to-date) libraries / bindings and tooling. At the end of the day that's what you do use for most of the work you're doing anyways - libraries. So suddenly you're doing all these bindings and battling tools instead of working on actual problem at hand. This gets tiresome real quick.

For some reason, and mostly that being Mozilla, Rust got quite an initial kick to overcome that initial hurdle in haste. We're not going to mention a lot of those libs are stale in Rust world, but at least they're there and that kind of gives you momentum to go forward. Whatever you're trying to do, there's a non-zero chance there's a library or something out there for you in Rust.. and we got there real quick which then encouraged people to proceed.

That's just like my opinion, man.. but I think a key part is that first lib bindings hurdle which Rust somehow went over real quick for a critical mass of it; D hasn't.

Love the D though lol, and Walter is a 10000x programmer if you ever saw one but it might be time to hang the hat. I can only imagine how a community like Rust or I don't know Zig of those up-and-coming would benefit from his help and insights. He'd probably single-handedly make rust compile 100x faster. One can hope.

I'd say that the compiler not being open source during the period when it might otherwise have become popular is probably a pretty big factor.

Articles like this I guess. If these are the 'lovable' features I'd hate to see the 'meh' features.

Automatic constructors - You only have to write the 'make me a box of two apples' code and not 'this is how two apples go into a box'! This is as revolutionary as 'automatic function calls', where you don't have to manually push the instruction pointer to pop it back off later.

Parenthesis omission!

If I were to parody this I'd talk about how good Scala is - in addition to classes, you can also declare objects, saving you the effort of typing out the static keyword on each member.

Sell me something nice! Millions of threads on a node. Structured concurrency. Hygienic macros. Homoiconicity. Higher-kinded types. Decent type inference. Pure functions. Transactions.

Lack of large “sponsors”.

Mostly wrong place at the wrong time, I guess :(

Plus the chicken and the egg problem. This is mostly from the AerynOS experience : it seems like if you want to write some moderately complicated code then you're becoming the upstream of many libraries. Especially now with Rust's popularity and ecosystem maturity on the rise, it's super hard to convince people (e.g. your boss) that you'd be better of with D compared to e.g. Rust.

Lack of sufficient tooling support was my issue. Debugging and autocomplete was a flaky mess in VSC. The plugin for VS pro wasn’t much better.

I did not like DUB at all. Its default behavior was to not segregate artifacts by configuration, and trying to change that was a headache.

It’s too bad, though. It’s a nice language, but I can’t see it making any inroads at this point.

IIRC it was weird and not that great in D1 era, and stalled for a very long time. There were also two competing incompatible runtimes.

Then came the D2 re-write which broke backwards compatibility and took another few years.

In the meantime everyone moved on

scala is probably the poster child for supporting every paradigm you might want to use :) oz/mozart has more but that was essentially a research/teaching language specifically designed to use a wide range of paradigms in order to demonstrate them.

The issue is most developers do not bother to write any, and the ones that are written are most-often vapid typing failures ("these`int`s cannot be negative" should be handled by a type). I studied this field in grad school, and the entire problem almost always devolves into convincing developers to engage with the system.

See Design By Contract, and the language that brought its ideas into mainstream, Eiffel.

What D or C++26 can do, is a subset of Eiffel capabilities, or more modern approaches like theorem proving in tools like Ada/SPARK, Dafny, FStar,...

Just a personal anecdote, Walter Bright's Digital Mars C++ compiler also had the contracts (D started life almost literally as recycled code from Mr. Bright's other compilers - he wrote a native Java compiler, a Javascript 1.3 stdlib, and a C++ compiler with a bunch of extensions.... smash those together and you have the early D releases!).

Anyway, I used the DM C++ compiler originally because it was the only one I could download to the high school computers without filling out a form, and pimply-face youth me saw "DESIGN BY CONTRACT" at the top of the website and got kinda excited thinking it was a way to make some easy money coding online.

Imagine my disappointment when I saw it was just in/out/invariant/assert features. (I'm pretty sure D had just come out when I saw that, but I saw `import` instead of `#include` and dismissed it as a weenie language. Came back a couple years later and cursed my younger self for being a fool! lol)

    struct Tag { ... } Tag;

?

I feel like this feature could be implemented on top of more universal features.

Checking input parameters is easy, just write asserts at the start of the function.

Checking result requires "destructor" block and some kind of accessible result variable, so you can write asserts in this destructor block which you can place at the start of the function, as well.

Checking class invariants requires a way to specify that some function should be called at the end of every public function. I think, it's called aspect-oriented programming in Java and it's actually useful for more things, than just invariant checking. Declarative transaction management, logging.

There are probably two schools of programming language designs. Some put a lot of features into language and other trying to put a minimal number of features into language which are enough to express other features.

I think they were introduced with Eiffel, which was all about design by contract

  const MIN_U32 = 0;
  const MAX_U32 = 2 ** 32 - 1;
  
  function u32(v) {
    if (v < MIN_U32 || v > MAX_U32) {
      throw Error(`Value out of range for u32: ${v}`);
    }
  
    return leb128(v);
  }

  subtype U32 is Interfaces.Unsigned_64 range 0 .. 2 ** 32 - 1;

  type U32 is mod 2 ** 32;

  First  : constant U32 := U32'First; -- = 0
  Last   : constant U32 := U32'Last;  -- = 2 ** 32 - 1
  Range_ : constant U32 := U32'Range; -- Range 0 .. 2**32 - 1

Yeah, these look excellent. Am curious if D's invariants can be traced back to Ada/Spark at all (I don't know much about Ada except that it has these sorts of safety features).

>The "invariants" thing is fantastic, I haven't seen anything like that before and it's great.

is it not the same as the one in Eiffel?

> Invariants are functions that run at the start and end of every public member function

these are just runtime assertions

EDIT: how am i getting downvoted for copy-pasting literally what the article verifies?

I think it's a great mix of features. I agree it would make sense to separate the wheat from the chaff, but if you're a mature adult, you should be able to decide which features are useful to you and figure a dialect that works.

In general, the design of the standard library is much less alien and baroque than the STL, and is more battries-included, so you spend much less time puzzling over incantations and more time writing code. The code you have at the end is also much more concise and readable.

Likewise, because D is in a lot of ways "C++ with fewer problems and papercuts", I spend way less time figuring out totally inscrutable C++ compilation errors.

Consequently, I can spend more of time writing code and thinking about how to use all D's nice features to better effect. Plus, given how fungible and malleable the language is, it doesn't take a lot of effort to rework things if I want to change them in the future.

Personally, I think this is the main reason D hasn't caught on. It's selling point is that it's pragmatic and doesn't shove a lot of dogma or ideology down your throat. This isn't sexy and there's nothing to latch onto. There are many styles you can write D code in... MANY more than C++: Python-style, C#-style, C++-style, C-style... hell, bash style, MATLAB-style, R style, whatever you want. But for some of these styles, you have to build the tools! The fact that all of this is possible is the result of combining one very practical and ergonomic programming language, with a thousand different QOL improvements and handy tools... plus top tier metaprogramming.

IMO, the major thing holding D back right now is also along the same lines. It offers pragmatism and practicality, but the tooling is still weak. Languages like C++, Rust, and Python totally outclass D when it comes to tooling... but you have to sacrifice flexibility and ergonomics for baroque madness (C++) or BDSM (Rust) or slow and impossible to maintain code (Python). The choice is yours, I guess!

> For example, function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183

> function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

None of them are required. What they do is provide enforcement of semantics that otherwise would have to be put in the documentation. And, as we all know, function documentation is always either missing, outdated or just plain wrong.

For a (trivial) example:

    void foo(int* p) { *p = 3; }

vs:

    void foo(out int i) { i = 3; }

In the latter, you know that `i` is being initialized by the function. In the former, you'll have to rely on the non-existent documentation, or will have to read/understand the foo()'s internals.

`out` definitely is a win. Let's look at `scope`:

    void foo(int* p) { static int* pg = p; }
    void bar(*) {
        int x;
        foo(&x); // oops
    }

vs: void foo(scope int* p) { static int* pg = p; } // compiler flags error

This is most definitely a memory safety feature.

In general, you shouldn’t judge a language by the complexity of its standard library implementation unless you are planning to implement a comparable library.

Application code often only needs a subset of the language and can be much more readable.

The standard library needs to use every trick available to make itself expressive, reusable, backwards-compatible, and easy-to-use for callers. But for your application code you certainly want to make different tradeoffs.

> The source code for the C++ standard library is much worse, of course

But you prefer C++?

(The D standard library is in the process of being re-engineered for clarity, but still, it is far more comprehensible than C++'s.)

.init is not necessarily 0. For int it is, but for float it's NaN. For char it's 255 and for an enum, it's whatever you have decided it is. enum thing { first = -1, second, etc. } This way, a variable of type thing has -1 as init value.

forum.dlang.org is also written in D.

The `.init` is there because the default initializer isn't always 0.

I'd love to see more of these. In fact, I think it would make an amazing language feature zoo. Mine are heredoc, underscores to format large number 8_098_162_123

I was wondering the same thing. I have done a few toy projects in Zig, but found some of the docs lacking when you start to get into the weeds.

Can you actually have proper tooling with templates based language? I think just like C++, how much effort goes into IDEs and still they are subpar. Because with templates, the code doesn't exist until you compile it, so at best you can catch templates instantiations during compile time and then add them to the autocomplete, but anything more advanced than that is not really possible.