Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ eric-p7 2 days 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.

▲dataflow 2 days ago | parent | next [-]

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

▲bachmeier 2 days ago | parent | next [-]

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

▲dataflow 2 days ago | parent | next [-]

>> the virality of the GC

> Just don't allocate with the GC

"virality" is not just a word you can ignore.

▲bachmeier 2 days ago | parent [-]

I don't understand. If you're a C programmer and want to avoid the GC, there's nothing to be viral.

▲dataflow 2 days ago | parent [-]

> If you're a C programmer and want to avoid the GC, there's nothing to be viral.

What you're suggesting is the moral equivalent of "it's easy to avoid diseases, just avoid contact with those infected", or "it's easy to avoid allergens, just avoid foods you're allergic to", or "it's easy to avoid contamination, just set up a cleanroom", or "it's easy to write deterministic code, just avoid randomness", etc.

Yes, there are things that are easy to achieve in the vacuum of outer space, but that's not where most people are interested in living.

▲brabel a day ago | parent | next [-]

Completely agree after trying it. Anything that may throw an Exception requires GC. There goes 80% of D code you could use. The rest becomes inaccessible for other, similar reasons quite often. Try writing D with @nogc and it takes 10 minutes to understand that. They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib)

▲dataflow a day ago | parent | next [-]

> Try writing D with @nogc and it takes 10 minutes to understand that.

Thank you. Yes, exactly. The problems aren't even subtle; it's impossible to miss them if you actually try. I don't recall even finding a reasonable way to concatenate or split strings on the heap and return them without a GC, let alone anything more complicated. It boggles my mind that people repeat the talking point that it's somehow practical to program with @nogc when the most basic operations are so painful. Nobody is going to drool at the idea of spending days/weeks of their lives reinventing nonstandard second-class-citizen counterparts to basic types like strings just to use a new language.

> They want to make the situation better but there’s just not enough people to tackle the huge amount of work that requires (I.e. changing most of the stdlib)

I don't agree that it's lack of manpower that's the problem -- at least, not yet. I think it's primarily the unwillingness to even admit this is a problem (an existential problem for the language, I think) and confront it instead of denying the reality, and secondarily the inertia and ecosystem around the existing language outside the standard library. It's not like the problem is subtle (like you said, a few minutes of coding makes it painfully obvious) or novel. The language has been out there for over a decade and a half, and people have been asking for no-GC version nearly that long. Yet, at least to the extent I've had the energy to follow it, the response has always been the canned you-can-totally-program-D-without-a-GC denials you see repeated for the millionth time here, or (at best) silence. If this sentiment has changed and I'm unaware of it, that's already significant progress.

Maybe the unwillingness to confront reality is due to the lack of manpower and how daunting the problem looks; I'm not sure. But it seems as bright as daylight that D is not going to be successful without solving this problem.

▲WalterBright a day ago | parent | next [-]

I use:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba...

It's pretty minimalist on purpose. I don't much care for kitchen sink types.

The BetterC is the no-gc version. Use the -betterC switch on the compiler.

Or, if you want a string result,

    import core.stdc.stdlib;

    string concat(string s1, string s2)
    {
        const length = s1.length + s2.length;
        char* p = cast(char*)malloc(length);
        assert(p);
        p[0 .. s1.length] = s1;
        p[s1.length .. s1.length + s2.length] = s2;
        return cast(string)p[0 .. length];
    }
I tend to not use this sort of function because it doesn't manage its own memory. I use barray instead because it manages its memory using RAII. D provides enormous flexibility in managing memory. Or, you can just leave it to the gc to do it for you.
▲dataflow a day ago | parent [-]

> I use: https://github.com/dlang/dmd/blob/master/compiler/src/dmd/ba... It's pretty minimalist on purpose. I don't much care for kitchen sink types.

I feel you're demonstrating exactly the problems I highlighted through your example here -- including the very lack of acknowledgment of the overall problem.

▲WalterBright 19 hours ago | parent [-]

The problem is there is no such thing as a string type that doesn't have problems one way or another.

The very simplest and straightforward way is to use the gc to manage the memory. It works very very well. All the other schemes have serious compromises.

That's why you can use the method most appropriate in D for the particular usage. I routinely use several different methods.

▲Zardoz84 a day ago | parent | prev [-]

Part of the problem it's trying to do too many things in too many fronts. They try to implement a borrow-checker a la Rust. But feels very poorly compared against the Rust version. It haves a "optional" GC, but it's a subpar GC. And lacks a way to use alternative GCs.

And funny, C++ has been copying many features that DLang have for many time ago. Beginning with the type inference (ie using "auto" to declare vars). And now, contractual programing and static reflection.

I really loved the language, but it's very sad that never manages to take off and become more popular and well maintained.

▲WalterBright an hour ago | parent | next [-]

> But feels very poorly compared against the Rust version.

It's a prototype to gauge the interest in having a borrow checker in the language. I did not continue with it because the interest is not there.

▲pjmlp a day ago | parent | prev | next [-]

That has been the main problem from my point of view, too much pivoting looking for the right crowd, without finalizing what was done before.

And while some features in other languages might have seen an implementation first in D, claiming first to the finish line as it usually comes up, even on this thread, hardly does anything for language adoption.

On the contrary, it is one reason less leave those languages, as eventually they get the features, and already have the ecosystem.

▲WalterBright an hour ago | parent [-]

If you don't mind waiting 10 years, sure!

▲gpderetta a day ago | parent | prev [-]

> Beginning with the type inference (ie using "auto" to declare vars).

GCC (and possibly other compilers) had typeof in the '90s well before D was first released. Macros in the form:

   #define    TYPEOF(name, expr) typeof(expr) name = expr
Were widely in use since then.

I'm sure that C++ borrowed concepts from D, but type deduction (not inference BTW) is not one of them.

▲WalterBright an hour ago | parent [-]

Extensions are not part of the language, which means that programmers tend to avoid using them.

▲bachmeier a day ago | parent | prev [-]

This completely misses the point of my original comment. A C programmer that wants to continue to use their knowledge and existing code will be very happy using D. You're describing someone that wants to use D without the garbage collector. Those are two completely different cases.

I've been happily using D for a better experience with C code for more than a decade. First, because it's extremely rare to need to completely avoid the GC for everything in your program. Second, because everything you want and need from C is available, but you can use it from a more convenient language. Sure, exceptions won't work if you're avoiding the GC (which doesn't have anything to do with C), but so what. It's not like C programmers are currently using exceptions. You can continue to use whatever mechanism you're using now.

▲zem a day ago | parent [-]

> Sure, exceptions won't work if you're avoiding the GC (which doesn't have anything to do with C), but so what. It's not like C programmers are currently using exceptions.

that works if your main use case for d is as a top-level wrapper program that is basically calling a bunch of c libraries. if you want to use d libraries you will run into ones that need the gc pretty quickly.

▲WalterBright an hour ago | parent [-]

I don't see how GC allocate exceptions would be a problem unless you're generating thousands of exceptions. Throwing an exception should, by definition, be an exceptional case.

▲bmacho a day ago | parent | prev [-]

According to them[0], D as better C is indeed just C with less footguns and some additional optional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use or ignore).

I don't think what hinders their adoption is their direction, everything they say they accomplished/plan to accomplish is ideal IMO.

[0] : https://dlang.org/spec/betterc.html#retained

▲dataflow a day ago | parent [-]

> D as better C is indeed just C with less footguns and some additional features like RAII (that one can use or not) or more comptime assumptions (again, that one can use, or ignore)

Having strictly more features (if we even assume that, which I don't think is accurate) does not imply better.

Javascript is just JSON with more features too. Is it a mystery that people don't ship Javascript code everywhere instead of JSON?

▲WalterBright an hour ago | parent [-]

What the "more features" do is replace the clumsy/inadequate/risky methods used in a less powerful language like C. For example, you don't need to use the C preprocessor to do metaprogramming. D offers a world class metaprogramming capability.

Another example is D enables nested functions. Yes, there are ways in C to do the equivalent, but they are clumsy and indirect.

▲unclad5968 2 days ago | parent | prev [-]

If I'm just coding C except a new syntax, why wouldn't I just stick with C?

▲dataflow 2 days ago | parent [-]

It's not just new syntax, you get other nice features too.

▲WalterBright a day ago | parent | prev | next [-]

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

▲dataflow a day ago | parent | next [-]

> D is The One Language to Rule Them All.

That's kind of why I said it's the "jack of all trades". It's not a bad language, it just doesn't beat any existing languages I know of in their own niches (hence "master of none"), so few people are going to find it useful to drop any existing languages and use D in lieu of them.

▲jibal a day ago | parent [-]

It's amusing to see someone telling the designer and implementer of a language that he has put decades of effort into that "it's not a bad language".

▲WalterBright 19 hours ago | parent | next [-]

I often hear a lot worse :-) No worries, it doesn't bother me. What pleases me are the people who use D, like it, and tell me they make more money using D because D is much more productive to write code in.

D also attracts expert programmers who are very comfortable using the GC when appropriate, stack allocation when appropriate, malloc/free, even ref counting. These are just tools in the toolbox, like I use socket wrenches, end wrenches, box wrenches, crow foot wrenches, pipe wrenches, monkey wrenches, etc. I don't try to use socket wrenches for everything.

BTW, the GC makes managing memory in compile time function execution trivial. Something that non-GC languages struggle with.

▲dataflow 17 hours ago | parent [-]

> What pleases me are the people who use D, like it, and tell me they make more money using D because D is much more productive to write code in.

I guess what I've been trying to say is that you would find yourself pleased much, much more often (and D being much more successful) if you recognized and addressed these high-level issues that people have been pointing out for decades, instead of denying them and going on forums telling customers why their expectations are wrong or unnecessary. I'm saying this because D really is a great piece of technology that got a lot of things right, except a few crucial details for some of the most crucial users. And it has had so much potential - potential that has been gradually lost largely because you haven't even recognized the flaws and hurdles that come with it.

It remind me of the infamous Dropbox comment. It's as if you invented FTP, but then whenever people told you it's hard to store & share files, you kept insisting that it's trivial with just a few simple steps on Linux, completely missing the massive market opportunity and the barriers you're telling people to walk through. https://news.ycombinator.com/item?id=9224

And I'm not saying all this out of out hate for D, but out of (at least past) love for it. I desperately wanted to see it succeed, but I gave up because I realized you simply did not see the Achilles heel that frustrates many of its users and that has held back its potential.

▲WalterBright 12 hours ago | parent [-]

Anyone is free to propose things for D, we have a process for it, or you can just post your idea in the D forum. Many do. You don't have to sit back and hope someone else does it.

▲tialaramex a day ago | parent | prev [-]

It's better than the feedback I would have for, to give an example, Bjarne Stroustrup. Bjarne has spent so far as I can tell almost all of his adult life on C++. It's a huge bloated mess, and though there are many other guilty parties I don't think I can even say he was a good influence.

▲jibal 3 hours ago | parent [-]

You and Dataflow seem to have no idea how the real world works.

▲quietbritishjim a day ago | parent | prev [-]

One of C++'s great weaknesses is that it is just a huge language with too much stuff in. There are lots of reasons why this is, not worth re-exploring, but the point stands.

There is a great irony that a replacement to C++ should have lots of features in it. (Not necessarily the same too-many features.) One of the key requirements of a real C++ alternative would be fewer language features.

▲pjmlp a day ago | parent | next [-]

It is telling that Ada and Rust are only ones that many people in the C++ community would ever consider.

Because at the scale many companies use C++, the additions into ISO C++, for how bad WG21 process currently might be, don't land there because a group of academics found a cool feature, rather some company or individual has seen it as a must have feature for their industry.

Sadly also a similar reason on how you end up with extension spaghetti on Khronos APIs, CSS levels or what have you.

Naturally any wannabe C++ replacement to be taken seriously by such industries, has to offer similar flexibility in featuritis.

▲quietbritishjim a day ago | parent [-]

> Because at the scale many companies use C++, the additions into ISO C++, for how bad WG21 process currently might be, don't land there because a group of academics found a cool feature, rather some company or individual has seen it as a must have feature for their industry.

Maybe it's just me but, sorry, I cannot parse this sentence.

▲trealira a day ago | parent [-]

I'm not them, but I'll try reordering the sentence to help you parse it better.

As bad as the WG21 process might be, the additions into ISO C++ don't land there because a group of academics found a cool feature; they land there because some company or individual has seen it as a must-have feature for their industry.

▲quietbritishjim a day ago | parent [-]

Thank you :-)

▲feelamee a day ago | parent | prev [-]

Why is a big number of features a problem? You can ignore them if you don't like/need them. Can you briefly explain which features can be thrown out and language will not miss a lot without them?

▲quietbritishjim a day ago | parent [-]

> Why is a big number of features a problem? You can ignore them if you don't like/need them.

You 100% cannot do that. I mean, you can if you're writing some toy project just for your own use. But as soon as you start interacting with other programmers, it's inevitable that some will use some other subset of language features.

> Can you briefly explain which features can be thrown out and language will not miss a lot without them?

I don't think that it's controversial that C++ is a huge language with many features, and I doubt I'm the best person to rehash that. One often quoted example is the multitude of ways to initialise a variable (Foo x = y; Foo x(y); Foo x = {y}; Foo x{y} and for default initialisation Foo x; Foo x = {}; Foo x{}; Foo x() (not really - that's the most vexing parse); Foo x = Foo()). There's multiple syntaxes to define a function including auto and decltype(auto) return types. There are const, consteval and constexpr - you may know the difference but I've forgotten. There are so many templating features that I wouldn't know where to start. Concepts are layered on top of that - which are useful and a good idea but no denying that it's layering extra complexity on top (which can be said for many C++ features). I've really just scratched the surface.

The thing is, I learned C++ over 20 years ago, when the latest standard was C++03 (which was essentially the same as C++98). Even at the time, C++ seemed like a bit of a chunky language (e.g., compared to C or Object Pascal - languages tended to be simpler back then), but it was achievable to mostly understand it all. But each revision that passed has added a huge volume of features. So I really feel how big C++ is because it's even big compared to (an older version of) itself. I've mostly kept up over the years but I can't imagine how I would properly learn the language today from scratch - I feel like you don't really stand a chance unless you've also been closely following it for decades.

▲GoblinSlayer a day ago | parent | prev | next [-]

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.

▲dataflow a day ago | parent | next [-]

I used "scripting" loosely (Python source files are frequently called Python scripts), I wasn't referring to shell scripts specifically. Feel free to pretend I said Bash or data science or whatever you want.

Re: your first sentence: I neither understand the logic nor do I understand how insulting the developer is going to help D succeed here even if the logic was sound.

▲GoblinSlayer a day ago | parent [-]

You handle technology as an emotional being? Well, that's strange. I thought it's more about tradeoffs.

▲bravetraveler a day ago | parent | prev [-]

Python is useful for scripts that go beyond strings. For instance: making a series of API calls, parsing/processing/mutating.

That's not data science or AI; "more famous" -- ridiculous distinction.

Fun fact: Ansible is orchestrated Python. Half your Linux distribution of choice is a pile of Python scripts. It's everywhere.

▲zem a day ago | parent | prev | next [-]

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

▲dataflow a day ago | parent | next [-]

I almost mentioned Go as another example of what it doesn't substitute for, but decided to cut off the list. But no, I don't think it fits that niche either. Go has a lot of features D doesn't have. Just off the top of my head: it's very simple, it doesn't have pointer arithmetic (yes, that's a feature here), it performs escape analysis to automatically extend the lifetime of objects that escape the stack frame, etc.

▲WalterBright a day ago | parent [-]

D does not allow pointer arithmetic in code marked @safe.

D does escape analysis from an alternative direction. If a pointer is qualified with `scope`, the compiler guarantees it does not escape the stack frame.

▲dataflow a day ago | parent [-]

I'm well aware of those, and they obviously don't fill the gaps here.

▲globular-toast a day ago | parent | prev [-]

Well that shouldn't be a mystery. Golang was marketed by Google.

▲p0nce a day ago | parent | prev [-]

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

▲sltkr a day ago | parent | next [-]

That's not “the” full quote; it's a modern variation of the classic quote.

▲Chinjut a day ago | parent | prev [-]

There is no documented instance of your "full quote" prior to the 21st century. It's certainly not the origin of the phrase "Jack of all trades, master of none".

▲WalterBright 2 days ago | parent | prev | next [-]

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

▲johnisgood 2 days ago | parent | next [-]

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.

▲WalterBright 2 days ago | parent | next [-]

That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

`map` is an operation on a data structure that replaces one element with another, in this case `a` gets replaces with `idup(a)`. The `idup` makes a copy of its argument in memory, and marks the data is immutable.

▲sureglymop 2 days ago | parent | next [-]

So it's basically a pipe or like the pipe operator in some languages? Looks interesting.

▲JdeBP a day ago | parent | next [-]

It has a fairly direct analogy in some languages. A C♯ programmer reading the above will immediately recognize the analogy to .Select(), .ToArray(), and so forth from LiNQ.

* https://learn.microsoft.com/en-gb/dotnet/api/system.linq.enu...

* https://learn.microsoft.com/en-gb/dotnet/api/system.linq.enu...

▲WalterBright a day ago | parent | prev [-]

Yup, it looks and behaves very much like Unix piping.

▲ a day ago | parent [-]
[deleted]
▲johnisgood 2 days ago | parent | prev [-]

> That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

How would it look like with this particular code? Just for comparison.

> The `idup` makes a copy of its argument in memory, and marks the data is immutable.

How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

▲zdragnar 2 days ago | parent | next [-]

See https://en.m.wikipedia.org/wiki/Uniform_function_call_syntax - the examples section has two side by side. The Nim language version is also pretty readable even if you're not familiar with it.

As for idup... The first several search results for "dlang idup" are all useful.

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

I presume you really don't like perl, ML based (ocaml, f sharp, rust) Haskell or K.

▲johnisgood a day ago | parent [-]

I love Perl[1] and OCaml. I dislike the rest. It depends on the task.

[1] https://news.ycombinator.com/item?id=44359539

> As for idup... The first several search results for "dlang idup" are all useful.

Yes, I am sure it was, I am sure an LLM would have helped too, but I think that is besides the point here.

▲zdragnar a day ago | parent [-]

Is it beside the point? Looking at that perl example:

$string =~ s/\d+/NUM/g;

I don't have a clue what is going on. Sure, I see the regex, but what is =~ doing?

There's only so far you can stretch most languages before you need to actually put in effort to learn them.

▲johnisgood 6 hours ago | parent [-]

"=~" is the operator testing a regular expression match. It should be obvious, because on the right side you see regex, and you ought to know what "=" or "==" does.

FWIW, I knew this as a kid, too, despite knowing absolutely nothing about the language at the time.

Anyways, you should read https://news.ycombinator.com/item?id=44463391 if you care about why I dislike the way D does it.

▲p0nce a day ago | parent | prev | next [-]

I don't think you're wrong, I have used D for 19 years and don't really use the UFCS dot style, it requires too much context. Just loops are more readable. In D you don't have much decisions forced on you tbh.

▲johnisgood 6 hours ago | parent [-]

I appreciate it.

▲spacechild1 a day ago | parent | prev | next [-]

> Reading the documentation?

Yes?

> I really want to look at the code and be able to know straight away what it does, or have a rough idea.

You said elsewhere that you love Perl. Would you say your sentence above applies to Perl?

▲johnisgood a day ago | parent [-]

It does not, but Perl is a much older language, and I have familiarized myself with it through actual discourses regarding its syntax, implementation details, and so forth. But in this thread? All I got was wrongful accusations and down-votes. I am done replying to this thread. Should have just let Walter reply, but that was not enough for you people, was it?

Funny though, because most of the things these people accuse me of are dead wrong, and my comment history is proof of that. In fact, I have been down-voted to oblivion for telling people to read the documentation. I guess we may have come full circle.

Glad we had this utterly pointless chat.

▲spacechild1 a day ago | parent [-]

I'm not a D user and I don't have a ball in this game. I just found your critique of D's syntax rather odd because it can be applied to basically any language one is not already familiar with. Maybe I'm wrong, but I don't think my response was particularly rude...

▲johnisgood 6 hours ago | parent [-]

I mean, to me it just looks ugly. Perhaps written in a different way, it would have been better. I have seen Haskell and Elixir code, but they were much less ugly.

Then again, it is entirely subjective, and we should not argue about taste.

To each their own.

▲quietbritishjim a day ago | parent | prev [-]

> > That code is an example of f(a) being equivalent to a.f(). You can do it the f(a) way if you prefer.

> How would it look like with this particular code? Just for comparison.

I do not know how to write D, so the following might not compile, but it's not hard to give it a go:

    copy(sort(array(map!(uniq(byLine(stdin, KeepTerminator.yes)), a => idup(a)))), stdout.lockingTextWriter())
> > The `idup` makes a copy of its argument in memory, and marks the data is immutable.

> How is one supposed to know this? Reading the documentation? I really want to look at the code and be able to know straight away what it does, or have a rough idea.

Are you serious? You are offended by the idea of reading documentation?This is not helping the credibility of your argument. Again, I'm not a D user, but this is just silly.

▲johnisgood a day ago | parent [-]

> Are you serious? You are offended by the idea of reading documentation?This is not helping the credibility of your argument. Again, I'm not a D user, but this is just silly.

If you knew me, and you read my comment history, you would have NEVER said that. It is not even a matter of reading the documentation or not. "idup" seems arbitrary, sorry, I meant the whole line sounds arbitrary. Why "a"? Why "a.idup"? Why "map!"? I was asking genuine questions. You do not have to bash me and see ghosts. I was curious as to why it was implemented the way it was.

I am an active speaker against people who hate reading the documentation.

And FYI, I love Perl[1] and OCaml[2].

[1] https://news.ycombinator.com/item?id=44359539

[2] You would have to check the comment history.

▲schveiguy a day ago | parent | next [-]

> Why "a"

`a` is a parameter in the lambda function `a => a.idup`.

> Why "map!"

This is definitely something that can trip up new users or casual users. D does not use <> for template/generic instantiation, we use !. So `map!(a => a.idup)` means, instantiate the map template with this lambda.

What map is doing is transforming each element of a range into something else using a transformation function (this should be familiar I think?)

FWIW, I've been using D for nearly 20 years, and the template instantiation syntax is one of those things that is so much better, but you have to experience it to understand.

> "idup" seems arbitrary

Yes, but a lot of things are arbitrary in any language.

This name is a product of legacy. The original D incarnation (called D1) did not have immutable data as a language feature. To duplicate an array, you used the property `dup`, which I think is pretty well understood.

So when D2 came along, and you might want to duplicate an array into an immutable array, we got `idup`.

Yes, you have to read some documentation, not everything can be immediately obvious. There are a lot of obvious parts of D, and I think the learning curve is low.

▲johnisgood 6 hours ago | parent [-]

Thanks for the reply.

> Yes, but a lot of things are arbitrary in any language.

I disagree, but to each their own.

> Yes, you have to read some documentation, not everything can be immediately obvious.

I do not disagree, but I wanted to know the rationale behind it ("map!(a => a.idup)")!

▲quietbritishjim a day ago | parent | prev | next [-]

I think perhaps you are not realising the negative tone of your comments. There is no way to read "How is one supposed to know this? Reading the documentation?" except sarcasm. No amount of good faith in unrelated comment threads changes this. I believe that's why you're getting downvoted - not because people are easily offended about D, as you seem to believe.

▲johnisgood a day ago | parent [-]

Well, I did not intend my statement to be sarcastic. It was a genuine question. Blame my lack of social skills, or the fact that I am on the spectrum. I was curious about the implementation details, i.e. why "!" (in map), why "a", why "idup", etc. That is not to say I am reluctant to read the documentation, I am more than willing, but I wanted to know the story behind it. I have ideas, but they might be wrong. I do not want to guess when I can have a direct answer from Walter.

▲WalterBright 12 hours ago | parent [-]

a!arg is used because I hated the look of a<arg> used in C++. (Using < > to bracket things when < means less than and > means greater than is always trying to short-circuit my brain.)

▲cxr a day ago | parent | prev | next [-]

> I am an active speaker against people who hate reading the documentation.

How is one supposed to know this?

▲johnisgood 21 hours ago | parent [-]

I dunno, check my comment history if you are so curious. Been down-voted for daring to say that people should be less reluctant to read documentation.

▲cxr 20 hours ago | parent [-]

I refer you to the context of this discussion—how it is we got to be here:

> How is one supposed to know this? Reading[…]?

▲johnisgood 6 hours ago | parent [-]

Are you asking me to find the comment where I stated that I "dislike" people who are reluctant to read documentation?

▲ a day ago | parent | prev [-]
[deleted]
▲johnisgood a day ago | parent | prev | next [-]

Look, I will not comment on D any further because it seems like it gets down-voted for no reason. Take your positive comments if you so wish, no need to down-vote the ones that express different opinions. You won. I will not be commenting on it any further. I shall NEVER be expressing my opinions on this language, nor will I ever raise any questions regarding the motivation for its implementation details.

People are too quick to use the "down-vote" button, and are too quick to judge. I love documentation, I write them. I am an active speaker against people who hate reading the documentation. This was not a case against reading documentation, yet people - wrongfully - believed so. People always glance past things like: "not fond of", and "in my opinion". It is tiresome.

This thread could have been educational, but instead it was a thread meant to bash me. It is my fault.

▲vips7L a day ago | parent | prev [-]

You don’t like instance functions?

▲johnisgood a day ago | parent [-]

I do not like this in particular:

  stdin
        .byLine(KeepTerminator.yes)
        .uniq
        .map!(a => a.idup)
        .array
        .sort
        .copy(stdout.lockingTextWriter());
I would like to emphasize that this is a personal preference. No need to continue to bash me over it.

I prefer Elixir's |> operator, if you want an example of something I prefer.

▲vips7L a day ago | parent | next [-]

What’s the difference?

    stdin
      |> byLine(yes)
      |> uniq
      |> map(a => aidup)
      |> array
      |> sort
      |> copy(stdout)
I’m sorry if you took it as bashing. It’s mere curiosity as I’ve never seen that preference before.
▲johnisgood 6 hours ago | parent | next [-]

For what it's worth, in Elixir you might write something along the lines of the following (this is a rough translation, I haven't tested it):

  IO.stream(:stdio, :line)
  |> Stream.map(&String.trim_trailing/1)
  |> Enum.uniq()
  |> Enum.map(&String.duplicate(&1, 1))
  |> Enum.sort()
  |> Enum.each(&IO.puts/1)
This is not equivalent in style or presentation to:

  stdin
      .byLine(KeepTerminator.yes)
      .uniq
      .map!(a => a.idup)
      .array
      .sort
      .copy(stdout.lockingTextWriter());
Personally, I find the D version visually unappealing (and confusing), especially the way "stdin" sits alone on its own line, followed by a sequence of indented method calls. The excessive use of dots combined with the indentation structure makes it look, to me, rather awkward.

That is just my own opinion.

▲WalterBright an hour ago | parent [-]

You can format it whatever way you like. D does not use formatting to impose semantic meaning.

▲johnisgood a day ago | parent | prev | next [-]

Is it a fair comparison? Would it work in Elixir? I have not seen it in Elixir projects as such.

▲Jtsummers a day ago | parent [-]

Adjusting for the actual Elixir functions, yes that would work. That's how Elixir's |> works, it takes the value from the left and passes it as the first argument to function on the right. Which is what the chain of calls in D is doing.

▲johnisgood 6 hours ago | parent | next [-]

I have not yet seen such long chains in Elixir. Could you show me a project where it is used?

"map(a => aidup)" caught me by surprise, too. Would Elixir do such a thing?

▲vips7L 11 hours ago | parent | prev [-]

Thanks. I don’t know elixir.

▲ a day ago | parent | prev [-]
[deleted]
▲amiga386 a day ago | parent | prev [-]

And yet... Perl is good with its chained operators acting on lists?

    print join '',
        sort { $a cmp $b }
        grep { !$seen{$_}++ } # = uniq
        <STDIN>;
▲johnisgood 5 hours ago | parent | next [-]

Oh and by the way, it does not look that different from that of Rust. :) I have came across a lot of Rust projects.

▲johnisgood a day ago | parent | prev [-]

I do not write such Perl code, but I have in the past.

▲ziml77 a day ago | parent | prev [-]

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.

▲giancarlostoro a day ago | parent | prev | next [-]

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.

▲zem a day ago | parent [-]

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

▲giancarlostoro 17 hours ago | parent [-]

I think it needs to do build its own GUI stack and not rely on any others, maybe take inspiration from tooling like Delphi's which allowed you to add themes on a whim.

▲zem 11 hours ago | parent [-]

I don't know, gtk has solved a lot of problems that you don't necessarily want to reinvent from scratch and the api is pretty consistent with an object oriented language

▲Keyframe 2 days ago | parent | prev | next [-]

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.

▲mamcx 2 days ago | parent | next [-]

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.

▲skocznymroczny 20 hours ago | parent | prev | next [-]

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.

▲jadbox 2 days ago | parent | prev | next [-]

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.

▲WalterBright an hour ago | parent | next [-]

The irony here is when I bring up D in a Zig thread, people complain about that. But I don't mind people bringing up Zig in a D thread.

▲pjmlp a day ago | parent | prev | next [-]

Being a Modula-2 like safety language with curly brackets, plenty of @ and .{ } characters already puts it off for me.

For me any alternative to Rust implies having automatic resource managment, eventually coupled with improved type system, in a mix of affine types, linear types, effects or dependent types.

Something that in regards to safety is already available today by using GCC's Modula-2 frontend, FreePascal and similar, is not bringing too much to the table, comptime notwithstanding.

▲wavemode a day ago | parent | prev [-]

I don't know if I would describe Zig as ergonomic per se. It has some nice features, but the main focus is on completely explicit control over low-level details. In its design Zig always chooses explicitness and programmer control over ergonomics. If a language feature requires a lot of compiler magic then it's probably never going to be added.

▲josephg a day ago | parent [-]

Yeah I think of Zig as a modern version of C. And Rust and (I think) D like modern versions of C++. Well. Given D's marriage to the GC, maybe its more like Go or C#.

I know its petty - I still can't get past how idiotic and frustrating it is that Zig treats unused variables as a compiler error. Its the worst of all worlds:

- Its inconvenient (I have to explicitly suppress them in my code with _ = foo)

- Once I've suppressed them, I don't get any compiler warnings any more - so ironically, it takes more effort to find and fix them before committing. I end up accidentally committing code with unused variables more than in Rust or C.

- And it totally breaks my flow. I like to explore with my hands and run my code as I go. I clean up my code after my tests pass so I can be sure I don't introduce new bugs while refactoring.

Zig's handling of unused variables seems like an unforgivably bad design choice to me. Its been raised by the community plenty of times. Why hasn't it been fixed? I can understand if Andrew Kelly doesn't program the same way I do. We all have our idiosyncrasies. But does he seriously not have any smart people around him who he trusts who can talk him out of this design?

It seems like a huge pity to me. It otherwise seems like a lovely language.

▲WalterBright an hour ago | parent | next [-]

D will complain about unreachable code. I'm not a big fan of that, as it makes it a pain for me when doing a binary search looking for the source of a problem.

▲WalterBright an hour ago | parent | prev | next [-]

D's use of GC is more like a friend than a marriage.

▲kristoff_it a day ago | parent | prev [-]

> Zig's handling of unused variables seems like an unforgivably bad design choice to me. Its been raised by the community plenty of times. Why hasn't it been fixed?

Because yours is just an opinion. It's perfectly legitimate to not like unused variable errors, but its factually wrong to say that no one wants it. You're just yucking somebody else's yum.

> But does he seriously not have any smart people around him who he trusts who can talk him out of this design?

He does, most of them also like unused variable errors. For what it's worth, I do too.

▲defen a day ago | parent | next [-]

The unused variables thing seems like it's downstream of "no warnings, only errors". That is, once you're committed to errors-only, then unused variables are either an error, or not. And if those are your only two choices, then errors sound better.

However, I've written a decent amount of Zig code and that's probably my biggest complaint. Zig has put a ton of effort into making an ultra-fast developer experience with very low iteration times, and it's amazing. But then when I'm refactoring some code or trying to figure stuff out by, for example, commenting out some lines of code, I might get a bunch of unused variable errors. And so I spend more time fixing those than I do even compiling the code itself!

One thing I've seen suggested is using the linter to automatically insert `_ = foo` for unused variables, but I don't love that either because then what even is the point of the error in the first place?

But like I said that's all downstream of the no-warnings policy. And I totally understand the failure mode of warnings - I've worked on plenty of large projects that had 4,000 warnings and everyone ignored them and the actually useful ones would be invisible. Is there some middle ground where, I don't know, Debug builds can have warnings, but Release builds don't?

▲WalterBright 43 minutes ago | parent | next [-]

D started out as a language with no warnings, for the reasons you pointed out. Unfortunately, warnings have crept in from the edges.

▲josephg 18 hours ago | parent | prev [-]

I’d go further and say that zig already respects / trusts developers enough to manage their own memory. Philosophically it’s already not a language for sloppy teams who would ignore 4000 compiler warnings if given half a chance.

Zig is a language that demands a lot of rigour of the programmer. It offers a lot of trust. Far more so than Go or even Rust. It’s in light of that philosophy that it seems so weird. The compiler trusts me to manually manage my memory, but it’ll scold me like a naughty child if I ignore an unused variable for 5 minutes? Pick a lane.

I’d love to hear some arguments in support of this choice. The closest I’ve heard is “it doesn’t bother me, personally” - which isn’t a very strong argument.

I’m a little tempted to fork the compiler just to fix this. Can’t be that hard, right?

▲josephg a day ago | parent | prev [-]

In that case, can you help me understand the logic behind it?

The more time I spend thinking about it, the more convinced I am that its strictly worse. What am I missing? Why do you like it?

▲ a day ago | parent [-]
[deleted]
▲steveklabnik 2 days ago | parent | prev [-]

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

▲Keyframe 2 days ago | parent [-]

for sure we did, Steve! Sometimes multiple times a day even, hah. Check out ‪@keyframe2 on bsky or @keyframe on the evil platform and let's reconnect.

▲steveklabnik 2 days ago | parent [-]

Ha, that was so long ago I can barely remember a lot of it. I’ll give you a follow!

▲nicoburns 2 days ago | parent | prev | next [-]

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.

▲destructionator 2 days ago | parent [-]

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.

▲LugosFergus a day ago | parent | prev | next [-]

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.

▲mrkeen a day ago | parent | prev | next [-]

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.

▲WalterBright a day ago | parent | next [-]

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!

▲zem a day ago | parent | prev [-]

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

▲WalterBright 35 minutes ago | parent [-]

What's interesting is that other languages have since adopted CTFE, but they missed the point and did it wrong. The usual mistake is to add a keyword necessary to trigger it. D triggers it when an expression appears where a "const-expression" appears in the grammar. I.e:

    int x = f(); // f() is run at run time
    enum y = f(); // f() is run at compile time
▲GZGavinZhao a day ago | parent | prev | next [-]

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.

▲WalterBright a day ago | parent [-]

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

▲nickpp 2 days ago | parent | prev | next [-]

Lack of large “sponsors”.

▲zem 2 days ago | parent | prev | next [-]

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.

▲troupo a day ago | parent | prev [-]

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

▲destructionator a day ago | parent [-]

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

▲WalterBright 34 minutes ago | parent [-]

I've actually tried to remove some features from D, but there's always someone who built a store on it.