On Sunday, 7 November 2021 at 07:12:20 UTC, zjh wrote:

Serving for ordinary users has no future.
Because other languages have occupied the field.
The expert user is the commanding height of the programming language, because only the expert writes the library.
Only when there are more experts writing the library can we form positive feedback.

On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:

Yes, I think you get this response because people have written successful applications for things like micro-services. But there is a difference between being usable and having solid support.

So the real challenge for D is focusing and providing solid support for something specific. I think everyone understands this. People who use D in professional contexts seems to be ok with creating their own frameworks, which requires dedication.

As of today D is for programmers with a high level of dedication. That basically puts D in the same category as C++ and Haskell, but not in the same category as Go, Python, Java etc.

That there are fewer programmers with a high level of dedication to a single language should not surprise anyone.

What does "GAT" and "HKT" mean?

Doesn't seem to be better than C++20 in that regard? How is Rust's error handling sophisticated?

Go is ok for tiny applications that fits well to their standard library, but the language does not seem to scale very well. I am not so sure about productivity. I want to see that measured in terms of long term evolution and maintenance.

I would prefer Java, but Go's runtime is lighter and spins up faster on the platform I use, so Go it is. Has nothing to do with the language, only runtime and stability. The JVM clearly provides better languages than Go…

D isn't stable enough. Both Java and Go have stellar backwards compatibility and that is critical for servers where you may be forced to upgrade over night (either because of security issues or because the cloud service requires you to).

Well, it is primarily C with some adjustments and additions. What is unfortunate is that the language does not fit well with global GC and there is no willingness to do what is necessary: switch to a GC model that is local to the computation and use reference counting elsewhere. (other options are also possible)

There is also little willingness to adjust the language, clean out inconsistencies, improve on C (like fixing the flawed operator precedence rules of C). These language issues are perhaps not so apparent for people who primarily use D, but stands out to anyone with a comp sci background or who use many languages.

I see people claim tooling as the "one issue". I don't think so. I think language issues come first, then eco system, then tooling. Can I prove it? No, but if you have quirks that is off-putting to highly educated programmers then that means less sophisticated eco system. This is particularly true for D and C++ as making good use of metaprogramming requires high levels of sophistication!

The one issue that truly prevents progress is that the language designers are happy with the language as is, and they are not interested in changes (only additions).

And its biggest disadvantage. However now that type annotations have been added, you basically have gradual typing in Python, which is very productive.

Moving target. You need vast resources to address the continuous changes on mobile platforms. The graveyard for mobile cross platform frameworks is enormous! It is improbable for D to succeed in this field.

D is retaining the disadvantages because features are being replicated from other languages rather than reinvented. If you want to combine low level programming with high level programming you need to go further away from the mainstream than D. (E.g. choose the actor model).

In order to reinvent, D needs to accept more breaking changes on the language level.

On Sunday, 7 November 2021 at 07:28:38 UTC, zjh wrote:

I agree. If meta-programming is meant to be D's strong feature then experts are invaluable, and you have to be willing to do what is necessary to get them interested (including breaking changes).

((However, experts also want to spend less time on boring tasks, so you also need some high level features.))

On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad wrote:

Generic Associated- and Higher Kinded Types

On Saturday, 6 November 2021 at 09:02:07 UTC, zjh wrote:

For me, a good tool is Qt adapted to D. It allows me to make beautiful applications with minimal effort. The documentation is the Qt documentation.

On Sunday, 7 November 2021 at 11:45:42 UTC, MGW wrote:

Does that work reliably now?

For the tasks I use, it's quite reliable. I haven't tried it in tasks that require long execution times or manipulating a huge number of Qt class instances. I see Qt as an ecosystem to hold on to, which can dramatically speed up application creation. The D place is between C++ and Python.

On Sunday, 7 November 2021 at 12:09:42 UTC, MGW wrote:

If You could write an introduction,
That will be good.
There is a great need for articles for D.

On Sunday, 7 November 2021 at 12:37:44 UTC, zjh wrote:

especially since the github page and repository is kinda confusing...

On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad wrote:

It is a very common response when people are enthusiastic about a particular technology. People for whom using D is a goal in itself are using it, but the others are not going to move to it for the sake of using D. They would do it if D solves some problems they are currently facing, or if it allows them to achieve their own objectives (which are probably unrelated to D) better than some other alternative.

But there are two aspects to this where in my opinion D is currently failing and both are more cultural than technical. That D "can" do something is not enough; that someone successfully wrote some app in D doesn't mean D is a good choice for that application field. Like any language, D must not just be good at something, it must be the best at something. It's fair to say that currently it isn't. The dlang community wants to push static if etc. as their killer feature but it seems that more often than not, it elicites a "meh" reaction.

The other problem is that D seems deeply allergic to making hard decisions. From reading this forum it seems to me that the overall attitude within D is that it should offer choices, not enforce decisions. But in the real world, that's often a bad thing. Another language with the same mantra was Perl. Look at what happened to Perl the moment we got Python, Ruby etc. Enforcing decisions is a Good Thing: it ensures that people understand each other's code, that analysis tools can do a much better job, that people won't roll out their own error management that doesn't work together with someone else's, that there will be consistency in memory management, etc etc etc. Once again, the two languages somewhat comparable to D that "made it", Go and Rust, are all about enforcing what they deemed to be their way to do things. That doesn't mean it's the only legitimate way, but it means that if you want to do X, this is how you do it in Go (not that there isn't a one true way, but you are free to try to devise 15 different ways). And if the Go way doesn't work for you, that's perfectly fine, there are other languages that would be a better fit for your problem. Same for Rust.

This is a hard lesson that D desperately doesn't want to learn. By trying to appease everyone it ultimately doesn't win for anyone in particular.

Not really. C++ has a huge wealth of frameworks, IDEs, tools and libraries that make its strength. Plus ever since C++11 it has been dedicated to recognising and attempting to fix its problems (although the solutions are often a kind of placebo: there is no way to ensure, for example, that unique_ptr is really unique, or that an object won't be accessed after std::move). I personally dislike C++ with a vengeance, but if you develop in C++, you will never be on your own. Not so with D.

Haskell is a different beast altogether. It's a niche language that knows exactly what it wants to be and especially what it doesn't want. It's the perfect solution for a specific area of problems. Which illustrates the discussion above.

Of course. But why should they? A language is nothing more than a tool. Carpenters are dedicated to building furniture, not to using a hammer.

Generic Associated Types.

HKT = Higher Kind Types. GATs are a subset of HKTs.

In several ways. Rust has proper sum types and a "match" statement that guarantees that all cases are covered (plus it has functional semantics). That alone makes it more general and safer than C++. It also has some syntactic sugar (like the ? operator) and the pseudo-monadic methods and_then etc. that together make it basically as easy to use as exceptions. But it has also the advantages that since all errors are in-band values, they are friendly towards multithreading and parallelisation. With the Rayon library (which provides parallel iterators) you can for example write something like:

let results = data.par_iter().map(|v| process_value(&v)).collect();

This will run process_value() in parallel on all elements of the data collection. If process_value() can fail (= it could throw in D or C++), it will return a Result. You will get a collection (like a Vec) of Results and you will be able to check which ones have succeeded and which have failed.

Using exceptions in multithreaded code is... no comment.

It seems that those who use Go, Google to begin with, beg to disagree that it's just for tiny applications. As for whether it scales well, its long term evolution and maintenance... how do you think it compares to D as far as hard data and proof of the pudding are concerned?

Of course it's also a big disadvantage. But notice the pattern: Python is dynamic - type annotations don't change that, it can still alter classes at runtime, reflect etc. It made that design choice and tries to offer developers all the benefits that go with it. And where it's not suitable, then you simply don't use Python.

It needn't be improbable. Kotlin was born as a third party project, like D but smaller. Google saw its benefit for Android development and embraced it wholeheartedly. It could have been D instead (and IMO it would make a nicer Android language than Kotlin). Making D target the JVM shouldn't have been a big problem. What was and still missing is consistency, well defined features that make sense for a stated goal, excellent tools and documentation and community dedication (to the application field, not to the language as such).

You are onto something there. Maybe an interesting and promising direction for D would be to get inspiration from Erlang as an actor-based application language, but with full C interoperability and a generally more conventional (and thus more approachable) language design. But once again, it needs to make the choices that are consistent with that, in full knowledge that it means saying NO to those features that aren't, and keep on track. It also requires a deliberate and long term community building effort. Go does it and Rust does it, but D still seems to believe that "if you just make a compiler, they will come".