Features of D That I Love

https://bradley.chatha.dev/blog/dlang-propaganda/features-of-d-that-i-love/

by vips7L • 1 year ago

198 258 1 year ago

bradley.chatha.dev

Alifatisk• 1 year ago

I like D, it's fascinating and powerful language. It made it even more curious when I watched Tsodings video on D. One thing that came to my mind when reading the article is that things like int.init instead of 0 and $ as shorthand for array.length does add to the mental load.

One good memory I had is a couple of years ago when I built a little forum using D. Man the site was blazing fast, like the interaction was instant. Good times.

WalterBright37• 1 year ago

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

fuzztester2• 1 year ago

forum.dlang.org is also written in D.

gallier24• 1 year ago

.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.

OskarS• 1 year ago

The "invariants" thing is fantastic, I haven't seen anything like that before and it's great. The C++26 contract stuff is fine, but this seems like a really great way of ensuring type invariants, I think I'd use this way more if it was in C++.

almostgotcaught3• 1 year ago

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?

jayd163• 1 year ago

I think there's something to be said about them running automatically that is lost when you say they're just asserts.

readthenotes1• 1 year ago

Maybe it's the editorial "just"?

Like: software programs can't be that difficult to create properly because they are just 1s and 0s.

LorenDB2• 1 year ago

Yes, but they are guaranteed to run at the beginning and end. C/C++ asserts need to handle any return path, whereas D has functionality to mark statements to run at the end of any return path while only being written once.

See also the scope(exit) feature.

destructionator4• 1 year ago

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)

WalterBright37• 1 year ago

The in/out features come into their own when inheritance is in play, i.e. for member functions of classes and interfaces. See https://dlang.org/spec/function.html#in_out_inheritance

`import` is so cool we extended it to be able to import .c files! The D compiler internally translates them to D so they can be used. When this was initially proposed, the reaction was "what's that good for?" It turned out to be incredibly useful and a huge time saver.

The concept is sort of like C++ being a superset of C and so being able to incorporate C code, except unlike C++, the C syntax can be left behind. After all, don't we get tired of:

    struct Tag { ... } Tag;

?

WalterBright37• 1 year ago

My C++ compiler also implemented contracts back in the 90s: https://www.digitalmars.com/ctg/contract.html

Modern C++ is slowly adopting D features, many of which came from extensions I added to my C++ compiler.

12_throw_away• 1 year ago

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).

johnisgood22• 1 year ago

Maybe this might help: https://news.ycombinator.com/item?id=44449835

peterashford• 1 year ago

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

johnisgood22• 1 year ago

Ada has that too, for what it is worth: https://learn.adacore.com/courses/intro-to-ada/chapters/cont... and https://en.wikibooks.org/wiki/Ada_Programming/Contract_Based.... It can be verified at compile time.

But what I love the most is: https://news.ycombinator.com/item?id=43936007

Instead of:

  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);
  }

You can do this, in Ada:

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

or alternatively:

  type U32 is mod 2 ** 32;

and then you can use attributes such as:

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

Does D have anything like this? Or do any other languages?

discardable_dan• 1 year ago

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.

wavemode2• 1 year ago

I find that is the case with almost all methodologies for software quality improvement. If you can't enforce that people follow it then it's not worth anything.

esafak• 1 year ago

It only takes one enlightened CTO :)

fuzztester2• 1 year ago

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?

vbezhenar• 1 year ago

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.

sirwhinesalot3• 1 year ago

Having the higher level abstraction built into the language gives extra semantic meaning that can be taken advantage of to build tooling. For example, one could build a symbolic model checker based on the contract specifications. It would be possible to do the same with the lower level features, but a lot harder if they aren't used consistently and correctly.

Same reason function calls are better than arbitrary jumps.

pjmlp7• 1 year ago

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,...

scrubs• 1 year ago

Beat me to it. Eiffel et al have been at the party for a while now.

eric-p7• 1 year ago

It's a mystery why D isn't far more popular than it is. Fast compilation, familiar syntax, and supports a wider range of programming paradigms than most (any?) other language.

nickpp• 1 year ago

Lack of large “sponsors”.

zem9• 1 year ago

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.

Imustaskforhelp• 1 year ago

Can you please specify more to be honest. This comment really catched my eye and maybe has pushed me to trying out scala but like my issue is that everywhere it says that scala primarily works good for OOP but like I know it can do functional too.

I am not sure if what supporting every paradigm is a definitely good thing though I feel like I would love the freedom to do so. I am a tinkerer at heart/first and a coder at second and my favourite language is probably go and then nim/julia/elixir/typescript/<it depends on the project>

nicoburns• 1 year ago

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.

destructionator4• 1 year ago

The D parts of the compiler were released under the GPL from almost the beginning, since 2002. By 2004, a full open source compiler - what we now call gdc, officially part of gcc - was released using this GPL code. D was pretty popular in these years.

Keyframe2• 1 year ago

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.

steveklabnik2• 1 year ago

I spent time back in the day with D as well, incidentally. I wonder if we crossed paths back then.

mamcx2• 1 year ago

Stressing the point, Rust ship very early with formatter, linter, cargo, rustup, and was not that behind in terms of editor support.

That is basically table stakes for a new language now.

jadbox2• 1 year ago

I've heard nice things about Zig being a more ergo alternative to Rust, but I haven't seen anyone compare it to D yet. From my brief testing, it seemed like Zig wasn't as ergo as D, but in theory it could evolve to maybe get there. From the outside, it doesn't seem like Zig has made any super major ergo improvements in the last year, but I could be wrong.

skocznymroczny3• 1 year ago

I liked D1 more than D2 too. D1 felt to me like a native C#, D2 feels to me more like C++ with GC. And I feel like there's been a lot of effort to satisfy C++ programmers, who will never invest into D anyway because they don't like the idea of GC. The ship has sailed, but I think D would get more traction amongst the Java/C# crowd instead of chasing the C++ crowd which is mostly going for Rust now anyway.

WalterBright37• 1 year ago

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

johnisgood22• 1 year ago

Is that really it? Why cannot you get a marketing budget, sponsored perhaps?

BTW:

I am not fond of stuff like:

  // 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());

Are there any ways to do this that do not involve a bunch of "."s? I do not understand "map!" and "a.idup" either, FWIW.

I really want to like D, but it tries to do too many things all at once, in my opinion.

Perhaps I will give C3 a fair try.

ziml77• 1 year ago

I wish you did have the marketing. I first read about D 10+ years ago and I continue to be disappointed that it never really took off. Having those hardcore users is great, but a language really is best with a thriving community and ecosystem. Languages like Go and Rust had the benefit of being able to kickstart those by having the backings of Google and Mozilla.

dataflow13• 1 year ago

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.

bachmeier5• 1 year ago

the virality of the GC makes it a non-starter for its primary audience (C/C++ developers)

No. If you were to say you need the GC to use all features of the language and standard library, of course, the GC does important things, but to claim a C developer wouldn't be comfortable with it because of the GC is nonsense. Just don't allocate with the GC and use the same mechanisms you'd use with C (and then build on top of them with things like @safe, reference counting, and unique pointers).

zem9• 1 year ago

it should at the very least fit the same niche golang does

WalterBright37• 1 year ago

With D you don't have to use multiple languages, such as mixing Python with C. D is The One Language to Rule Them All.

(D's ability to use C code is to make use of existing C code. There's not much point to writing C code to use with D.)

GoblinSlayer3• 1 year ago

When you use many languages, don't you become a jack of all trades, master of none? Also it's not obvious python is good for scripting, bash is better at short scripts, statically typed languages are better at long scripts, and you can't use it in CI yaml scripts. Python is more famous for data science and AI, not for scripting.

p0nce4• 1 year ago

The full quote is: “Jack of all trades master of none, though oftentimes better than master of one.”

GZGavinZhao• 1 year ago

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.

WalterBright37• 1 year ago

Where D shines is how readable D code is compared to other languages.

troupo2• 1 year ago

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

destructionator4• 1 year ago

D2 re-write

No such thing happened. D has always been built on the same codebase, and the labels "D1" and "D2" are just arbitrary points on a mostly linear evolution (in fact, the tags D 1.0 and D 2.0 came only 6 months apart; 1.0 was just meant to be a long term support branch, not a different language. It was the addition of `const` that broke most code around release 2.6 but if you update those, old and new compilers generally work.

I'd say where D failed was its insistence on chasing every half-baked trend that someone comments on Hacker News. Seriously, look at this very thread, Walter is replying to thing after thing saying "D has this too!!" nevermind if it actually is valuable irl or not.

mrkeen• 1 year ago

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.

WalterBright37• 1 year ago

D has pure functions:

https://dlang.org/spec/function.html#pure-functions

D's pure functions are quite strict. It can be a challenge to write a function that passes strict purity guarantees - but the result is worth it!

zem9• 1 year ago

compile time function evaluation is "nice" in the same way those features are, isn't it?

giancarlostoro3• 1 year ago

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.

zem9• 1 year ago

Another area where D could shine is GUIs

I've often thought that, to the extent that I spent a while looking for some active projects I could contribute to, and came up blank. if I do have some new gui based program of my own I want to write I will at least consider d for it, though ocaml is another great language in the same space and I already have some experience with ocaml/gtk. my hope was that d would have more mature gui toolkit bindings and more of a community of people writing apps, which would have been some incentive to switch over from ocaml, I was disappointed to find that wasn't the case.

LugosFergus• 1 year ago

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.

mamcx2• 1 year ago

I don't use D but think that error handling is one major feature:

https://dlang.org/articles/exception-safe.html

In concrete, looks to me to be the only language that covers the major ways to do it.

(In concrete the `scope` way is the one I found inspiring. . I think the exceptions can go and be replace by it for langs where exceptions are removed)

WalterBright37• 1 year ago

`scope` is very good at its job. It guarantees that a pointer passed as an argument does not escape the caller's scope. I find it almost as useful as transitive `const`.

elcritch3• 1 year ago

Syntax - UFCS (Uniform Function Call Syntax)

UFCS is such an underrated language feature. When you have UFCS you can toss out 90% of the uses of methods in favor of just plain ole functions. Add generic functions and concepts and you rarely end up needing OO support.

jayd163• 1 year ago

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

WalterBright37• 1 year ago

It works for all functions that have parameters, `f(a)` and `a.f()` are equivalent.

nicwilson• 1 year ago

`private` is only private to the module, not the struct/class, (In other words, all functions in the same module are all C++ style `friend`s) and so free function in same module work.

layer82• 1 year ago

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.

Doxin5• 1 year ago

There's nothing preventing UFCS from working with code completion. e.g. given:

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

You can now write code like this:

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

There is absolutely no reason that typing "foo." would not suggest "addOne" as possibility.

kmarc2• 1 year ago

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.

kyleee• 1 year ago

Quirky and awesome

girvo• 1 year ago

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

elcritch3• 1 year ago

Haha, Nim is my preferred UFCS language.

pjmlp7• 1 year ago

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

sirwhinesalot3• 1 year ago

I always find it funny how people focus on the .method() syntax. You have the "pipe" operator in some functional languages that achieves the same thing, pass the result of an expression as the first argument of the chained call on the right. Nothing to do with OOP.

motorest5• 1 year ago

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.

zozbot2345• 1 year ago

Implementation inheritance is generally a misfeature, especially in modern languages with proper generics. If you insist on having it, you can replicate it manually by using interface inheritance and the generic typestate pattern.

azhenley• 1 year ago

I really enjoy these lists of interesting features from various languages. They pop up occasionally on HN but now I can’t find them (Hillel Wayne had multiple).

I want a meta list of all these interesting features across languages.

EDIT: I found one! “Micro features I’d like to see in more languages” https://buttondown.com/hillelwayne/archive/microfeatures-id-...

sitkack• 1 year ago

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

gallier24• 1 year ago

D has them both

throwawaymaths3• 1 year ago

$ operator. great idea! i believe the only contender is julia (with "end" but that is a SUUPER awkward keyword since end also closes functions)

Structs and classes can even overload this operator

nope. fuck, now it's a terrible idea

bachmeier5• 1 year ago

I don't see why it would be a terrible idea. It's pretty convenient if you're slicing a multidimensional array.

throwawaymaths3• 1 year ago

except are you sure that's what it's doing? it could have been overloaded. you have to ask yourself that every time.

sedatk• 1 year ago

i believe the only contender is julia

C# has "^n" notation that means "length - n". For example:

Take the last element of an array or any other structure that supports indices:

    var a = ar[^1];

Take the last three elements of an array or any other data structure that supports ranges:

    var lastThree = ar[^3..];

WhereIsTheTruth3• 1 year ago

I'll take this:

    Vec2 result = translation + (rotationMatrix * (scalingMatrix * point));

Over this:

    const result = vec2Add(translation, mat2MulVec2(rotationMatrix, mat2MulVec2(scalingMatrix, point)));

Anytime

And that's a very simple example, in Zig, that kind of equations doesn't scale well, when it comes to readability

ioasuncvinvaer• 1 year ago

A problem that I always run into with code using * for multiplication of matrices is which operation they use. Is it element wise or a matrix multiplication?

jadbox2• 1 year ago

Has anyone compared D and Zig? I originally learned D over one weekend and then went on to completed several code competitions- the ergonomics of D are just fantastic.

ImPleadThe5th• 1 year ago

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.

zzo38computer• 1 year ago

In my opinion, some features of D are good, but I do not like all of them.

CTFE is good.

I do not really like the UFCS; if you want it to be used like a member of the first parameter then you should define it as a member of the first parameter (possibly as a inline function that only calls the freestanding function with the same name, if that is what you want it to do). (You could use a macro to do this automatically if you want to.)

Scoped imports is good, but I think that scoped macros would also be helpful.

Exhaustive switch seem like it might be better if designed differently than it is, but the idea seems to be not bad, in general.

LorenDB2• 1 year ago

UFCS is a bit overreaching but I think it's great for its intended use of chaining expressions on ranges and such.

destructionator4• 1 year ago

that actually wasn't its intended use; that's a side effect. The original intended use came from Effective C++ by Scott Meyers: "Prefer non-member non-friend functions to member functions.". It was meant to make that as syntactically appealing as the members.

Doxin5• 1 year ago

Honestly the main reason UFCS is good is when you don't "own" the type your function would need to be a member of. Most common one I run into is the "to" function from the stdlib. You can do this:

    import std.conv;
    
    int foo=3;
    string bar = foo.to!string

But now lets say you want to convert ints to MyCustomInts? You can hardly attach a new "to" member to int, but with UFCS it's easy. Just declare a to function anywhere in scope:

    MyCustomInt to(T)(T v) if(is(T==int)){
        return MyCustomInt.from_int_value(v)
        // or however you actually do the conversion
    }

and it'll magically work:

    int foo=3;
    MyCustomInt bar = foo.to!MyCustomInt;

burnt-resistor• 1 year ago

Invariants, dependent typing, and refinement types FTW.

In Rust land, it really need integration of something like flux into the language or as a gradually-compatible layer.

Can't have safe software without invariant checking, and not just stopping at bounds checking.

tealpod• 1 year ago

D is one of the most beautiful and very efficient language. I wonder why it never got the attention it deserves.

bachmeier5• 1 year ago

Interesting that there's nothing on there about C interop (likely reflecting the use cases of the author). D does it all: ImportC (compile C code), BetterC (make a D library part of a C program), and easy C interop in both directions.

kwoff• 1 year ago

Dlang always makes me think of two things: Walter Bright, resident of Hacker News. And awesome games I played on Linux in the 2000s: https://en.wikipedia.org/wiki/ABA_Games

sirwhinesalot3• 1 year ago

All wonderful features. Design by Contract in particular is massively underused in mainstream languages.

randomNumber7• 1 year ago

When I last looked at D they did a lot of interesting stuff with compile time function execution and s.th. like dependent types that they hacked into the language.

Can someone give me an update about the current state of this?

trikko• 1 year ago

The only missing thing is a big sponsor. mozilla -> rust google -> go, kotlin ... n/a -> dlang

WhereIsTheTruth3• 1 year ago

I am an avid fan of D, but they seriously need to massively invest into tooling

The current LSP is _that_ bad, it doesn't even recognize most notable D features such as templates and named arguments..

This should be their #1 priority, as the language is starting to get steam again, they should not miss tat opportunity

I know Walter does not use that kind of tools, but that's becoming a requirement nowadays for young developers

Please, invest into tooling!

skocznymroczny3• 1 year ago

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.

WhereIsTheTruth3• 1 year ago

Odin have a great LSP, it supports everything the language offers, generics, unions, bitsets, using, same with Zig, their LSP supports most of the notable features even comptime..Both language are quite new, relatively to D

There is no excuse for D, if they can make a great compiler, they surely can make great tooling too

I suggest you give the D LSP a try, I have mentioned templates, but it's very frail for everything else, using `auto`, having a chain of identifiers or even using reference/pointers is enough to confuse it, most of the time

I think it stems from the fact that both Zig/Odin provide a parser/lexer as part of their std, making it easier to just focus on building the tools, the community built parser is not good and lags behind

coldtea• 1 year ago

Not the D I expected from reading the title

(come on, a low effort joke now and then is ok, if not for anything else, as an counter-example)

p0nce4• 1 year ago

Strangely my favourite feature after 18 years of D programming (!) is that could place keywords largely in the order you like. It is strangely liberating to be able to put:

    pure nothrow @nogc:

    pure:
    nothrow:
    @nogc:

    pure nothrow @nogc
    {
        block
    }

Sometimes this helps readability.

quietbritishjim7• 1 year ago

Am I missing something? Those three keywords are literally in the same order in all the examples.

p0nce4• 1 year ago

Sorry, those keywords work in block like those, or relatively to a single function, in any order.

Joker_vD• 1 year ago

Invariants are functions that run at the start and end of every public member function, and can be used to ensure that the type is always in a valid state.

The ironic thing about this is that it means that the public functions of an object can't, generally, call each other willy-nilly unless they take special precautions: very often, the object's invariants are broken when the execution is in a middle of the object's method. This is not a problem with D, the language merely helps you to uncover this lurking problem which usually simply goes unnoticed until something breaks and someone notices it.

WalterBright37• 1 year ago

Yes, a subtle but very important point!

DLoupe2• 1 year ago

For me, D failed to replace C++ because of lack of design. It is more a mix of great features. But once you start learning the details simple things can get very complicated.

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

Another example is conditional compilation. Great when used sparely, but can otherwise make it very difficult to understand how the code flows.

In the end, reading the source code of the standard library convinced me against it.

(The source code for the C++ standard library is much worse, of course).

troupo2• 1 year ago

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

sfpotter• 1 year ago

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!

senkora• 1 year ago

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.

WalterBright37• 1 year ago

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.

WalterBright37• 1 year ago

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.)

DLoupe2• 1 year ago

Thanks so much for replying, Walter. I'll give it another try.

RcouF1uZ4gsC• 1 year ago

The reason that D did not replace C++, IMO is garbage collection.

D was so far ahead of C++98 that it wasn't funny, but garbage collection kept it from being able to be used in the same niche.

D has gotten less dependent on garbage collection but

C++11 (and then 17, 20, 26 (reflection)) have closed the gap enough that it is not the quantum leap that it once was.

skocznymroczny3• 1 year ago

I hope some day D gets some WASM story going. Right now the support is very limited, pretty much only through the C subset of D which defeats the point. Supposedly the GC was the main issue, but other GC enabled languages are already thriving in the Web (Go, Java, C#).

There were some efforts to enable D on the web but it seems like these are mostly one man efforts that implement only the minimum features that their specific projects required.

Features of D That I Love

Related Stories