On Sunday, 20 March 2022 at 11:11:03 UTC, bachmeier wrote:

I have indeed written a couple of lines in D, in case you are interested I have ported a compiler from Java to D, a low level memory allocator from C++ to D, and a few OpenGL demos.

Have I ever delivered any D into production?

It would be great, but that isn't what puts bread on the table, rather Java, C#, C++ is what customers ask for, and increasingly they are starting to occasionally also ask for Go and Rust knowledge as differentiation factor.

My critics of D, that you take so personally, are usually meant as a reality check for a language that I follow since Andrei has published his book.

All these years people keep comparing D to other languages, while in meantime the other languages got most of the features that made D innovative a decade ago, with an ecosystem that D will never have, yet keeps being ignored when bashing other languages for lack of D features.

Be assured I won't be stealing forum threads any more (to use your own words), it is clear it is a waste of my time and the audience here.

On Sunday, 20 March 2022 at 10:55:49 UTC, bachmeier wrote:

Yes I did, the whole paragraph is about the topic. I said the example given is something that can be a single function you use as a utility. This can be a single header file in C++. Once you write the function it can be used again and again. Now C++ isn't perfect so you have to write the code yourself but it's a relatively simple function to write. On the other hand D has a problem with much more difficult problems to write, just like the std library is a library, there aren't many third party libraries that are of good quality. Including the STD library itself, as it too is a library to be criticized. And then I give an example.

All the above information is there just compressed. Sorry I inferred a few common knowledge things I thought were common knowledge and I ended up writing it in a more compact form.

They are related or are we not talking about a function or utility function in a library and we are talking about how one library doesn't have that utility function. Now just replace utility function with a class instead. It's basically the same thing, your just arguing a straw man argument to dismiss the criticism instead of just addressing the criticism.

On Sunday, 20 March 2022 at 13:50:54 UTC, Paulo Pinto wrote:
...

I've enjoyed your writing and observations on a number of occasions and hope to see more in the future

In line, I believe, with many of your posts I can see a lot of good reasons to avoid D at this time: if you are a contractor, or work to support/extend a very large code base, or have conservative management, or prefer cut and paste development or ... then D is probably not for you.

OTOH, if you aim to disrupt then D could be a great choice.

On Sunday, 20 March 2022 at 14:56:45 UTC, Bruce Carneal wrote:

I don't think a language has to be commercially viable for corporations in order to be interesting to use, but Paolo is spot on when it comes to D having lost direction and falling behind…

It is better to just say that competing head-to-head with C++ is not a goal than to give the impression that it is while spending time on things that doesn't provide any advantages for existing C++ programmers (e.g. weird string interpolation etc) and also not having a clear plan for reaching parity with C++17. If D ever gets there with this lack of focus you'll be up against C++26 when D has the C++17 features set and you will stil not be able to win over C++ programmers.

But is totally fair to create something in a direction completely different from where C++ is heading, if that is more interesting to the D designers, but then they should forget everything they think they know about C++ and create something novel.

In general, there are too many languages now that are almost-the-same, so if going head-to-head with C++ isn't realistic/fun… then stake out a niche that isn't already filled with other languages.

(my personal opinion is that going for per-actor-gc and ARC could be interesting enough to create a distance to most other languages).

On Sunday, 20 March 2022 at 11:11:03 UTC, bachmeier wrote:

I think Paulo and others are responding to the underlying statement that the OP was trying to say, that D is better than C++ and this is why we should prefer D over C++
(Atleast that's what I inferred)

They point out that feature superiority does not compensate for the ecosystem fragility(I'm not saying this, that just seems to be the sentiment echoed by them)

It's a little frustrating to read, but one can just gloss over if they don't want a dose of negativity(or "reality", I guess).

On Monday, 21 March 2022 at 13:36:47 UTC, Tejas wrote:

You cannot point to individual features (and especially not make assumptions about a feature that was added in C++20) and claim that it is somehow significant. You have to look at the whole package and how the features play together for a specific use case. Whether the eco system matters or not also depends on the use case (in many C++ scenarios you don't build on many external libraries, so that may or may not be significant, depends on the context).

You might argue that string mixin is a superior feature. Although that feature makes code much less maintainable (read the source code for the D standard library and you'll see why), so whether you classify that as an advantage or a way to aggregate debt and increase costs over the project life-time depends on whether you write larger programs that are maintained over a long period of time or not.

In the real world language-specific features have little impact on application development unless you use them to a large extent. Does anyone have a list of usage scenarios for compile time strings without string mixins that would motivate a programmer to shift to another language to get it? I've never had the need for it outside string mixins, so I would argue that how features play together typically is more important than any individual feature.

Right now, D lacks basic things that C++ programmers would expect, so if you want to sway them to switch over it is rather pointless to point at things they rarely need, or that they can implement in a few hours, or that is in the pipeline for C++23/C++26.

You need to point to a plan for how D is going to address those features they feel lacking.

Or, given the stagnation of D, it might be much better to stop focusing on C++ and do something completely different from what C++ does.

On Monday, 21 March 2022 at 15:23:21 UTC, Ola Fosheim Grøstad wrote:

Stealing a bit of Symmetry Investments prototype code I'm currently working on to demonstrate.

template addMonthsStick(DateType) {
    @SILdoc("Adds m number of months"
        ~ " to a " ~ __traits(identifier, DateType)
        ~ "[snip the rest of doc description]"
    )
    DateType addMonthsStick(DateType arg, long m) {/*...*/}
}

IOW, generating documentation for Symmetry Integration Language function at compile time.

Also, https://code.dlang.org/packages/pegged. While it works with string mixins, you can also make a separate program to generate the parser for your main project. That way you avoid having the compiler processing the PEG over and over again at compile time.

On Monday, 21 March 2022 at 16:07:44 UTC, Dukc wrote:

template addMonthsStick(DateType) {
    @SILdoc("Adds m number of months"
        ~ " to a " ~ __traits(identifier, DateType)
        ~ "[snip the rest of doc description]"
    )
    DateType addMonthsStick(DateType arg, long m) {/*...*/}
}

Ok, so you use it to access reflection within the compiler instead of using "compiler as a library".

Not sure why you would do this as a compile time evaluation if you run it separately anyway?

Both these use cases are what I would consider "auxiliary usage" and not so much relevant for building libraries IMO, although being able to extract information using reflection is nice workaround if you don't have access to an "compiler as a library" feature.

On Thursday, 17 March 2022 at 16:56:12 UTC, kdevel wrote:

Read all data from file descriptor:

File f;
f.fdopen(STDIN_FILENO, "rb");
auto inbuffer = f.byChunk(4096).join;