On Saturday, 6 November 2021 at 02:43:44 UTC, Dr Machine Code wrote:

Something suitable for audio-visual applications. Something you could use to build visualization tools, photo editors, audio editors, training software, simulation tools, simpler games…

A framework for building the kind of desktop applications where you still benefit from native compilation and OS features.

On Saturday, 6 November 2021 at 08:19:29 UTC, zjh wrote:

I've been thinking about this for about 9000 years now and I think tooling is the answer. Why? Because developers are used to it now. And are lazy.

When I first came to D from C# I was just screaming into the void. Where was my static analysis, intellisense and refactoring tools.

I don't know what made me continue my journey, but I'm glad I did.

With that said though, for D to succeed we need better tooling around the language.

On Saturday, 6 November 2021 at 08:19:29 UTC, zjh wrote:

We need to work hard on vscode/VIM plugins for D users.

On Saturday, 6 November 2021 at 08:52:42 UTC, Imperatorn wrote:

D community should find several people to provide excellent VIM/vscode plug-in tools.
In fact, many people (really) like D, they just lack good tools.

Maybe we can investigate the special tools like ide/editors of programmers in other communities(c++/rust), and then work on it.

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

For example, people say that it is difficult to complete the automatic completion of ucfs/template mixin, so we should find a way to solve it ,then provide tools to vim/vscode plugin.

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

Dlang can now already easily takeover Golang programmers: 'go generate', absence of generics and other language features and low expressiveness of Golang, makes Dlang already better.

As for Rust: I don't think Dlang should compete with it directly, thou Dlang can obtain optionally Rust's 'strong' features and by this make self more attractive to those who choose Rust.

But in general, there are too few projects, which can display Dlang's awesomeness, while for Golang it's Docker and Kubernetes and for Rust it is Mozilla programs.

IMHO, If Dlang would have something like Web-engine written on it.. or may be if Dlang had own Linux-kernel replacement, or maybe some DBMS (for instance RethinkDB fork or Cassandra fork), or OpenShift substitution - this would be huge!

On Saturday, 6 November 2021 at 11:09:24 UTC, Alexey wrote:

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

https://go2goplay.golang.org/

While D keeps trying to decide what market it should cater to, others keep closing the gap, while having better ecosystem.

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

It's because the leaders of D do not want it to be popular. D's popularity is manifest of their attitude about it. They don't care any more. It's just their golf game, simple as that.

On Friday, 5 November 2021 at 13:10:58 UTC, Guillaume Piolat wrote:

I know it's not the point of view of many in the D community, but at least in part this topic is all about the gap between the PoV of the D community vs the rest. When the D community believes D has many advantages but the rest of the developer community is not rushing to embrace it, and when at the same time the OP asks why is it so, then it's fair to ask whether they might actually see certain things that the dlang community just doesn't want to recognise.

For low-level systems programming, Rust is fully committed to manual memory management unlike D with its schizophrenic attitude towards the GC. Together with the borrow checker, Rust can offer some static guarantees that D can't and which are especially important in low-level code. However unlike Phobos, using Rust that way also doesn't require you to forego the standard library. At the same time, its type system is richer than D's, with full Hindley Milner inference and especially now that GAT's are being stabilised and the language is basically on its way to support HKTs. It also offers sophisticated error handling without using exceptions (another big win in low level code).

Many people have forgotten it now but at one point, Rust had classes with inheritance as well as a GC. It was concluded that those features didn't belong in a systems language and were removed. This is probably Rust's greatest strength over D: its consistency, the follow through to ensure that features that are declared stable are really rock solid and make sense within the language's general philosophy. Sometimes the choice made is the wrong one, of course (the async semanitcs don't really play well with Linux's new io_uring API, for example), but even then, the community is fully committed to support them into the future with all the care it takes, and find solutions that work whenever they made the wrong call. Add a homogeneous ecosystem, top notch tooling and documentation and it's easy to see why it has been so successful.

The second example was Go. It's often criticised for being a limited language with not much expressive power. Undeniably D's modelling power is far greater than Go's. It's also largely irrelevant: Go still doesn't even have generics in stable and it hasn't slowed down its adoption. Why? Because Go's designer knew their target: corporate coders whose only concern is productivity and time-to-market. Go is not "elegant" or rich or powerful, but it's extremely easy to use and quick to get things done. GC is an advantage for those application and Go's is best of breed. D's situation here is a kind of lose-lose: it is primarily and clearly a GC langauge, which hampers its use for low level code, yet where a GC is desirable, it can't compete with Go's GC. Goroutines are another big item: a web application developer needs to react asynchronously to an event and calling "go process_stuff()" is an immediate answer. They want the code to work today, not spend time marvelling at how cleverly (or "cleverly") a framework that doesn't compile any more with a recent compiler used to implement it through template metaprogramming. Go gives them that and the time and effort it saves is worth every penny.

In many ways, Go epitomises an important trait of the Zen of Python: for every problem, there is one obvious way to do it. That's exactly what that programming community wants: a language that gets out of their way and just gives them the simple, basic building blocks (but of excellent quality) that allow them to solve their actual problem.

Regarding Python, its biggest advantage (other than its outstanding ecosystem) is that it's a dynamic language. Prototyping, testing, customising etc will always be easier and more flexible in Python than in any compiled language. Plus its conscious focus on a simple syntax makes it in my opinion the modern day heir to the BASIC of the 80s in terms of universal applicability and a kind of immediacy.

So where does that leave D? Someone here mentioned mobile development. IMHO that is one huge missed opportunity for D. It could have been a language of choice on Android (better than either Java or Kotlin). But note that no-one develops mobile applications in C, C++ or Rust. That's because once again, it requires a language that seamlessly blends with the APIs, doesn't bother the developer with the minutiae of memory management etc. D's general approach has been to always try to have its cake and eat it too. It wants a GC but at the same time wants to pretend that it doesn't need a GC, it wants to support OOP (with inheritance etc) and at the same time tries to downplay it, etc. Ultimately in each of these cases it fails to provide the advantages of either of the valid choices while retaining the disadvantages of both.

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

D needs to provide options, not mandatory.
utf8, auto decoding, GC, are all like this. They are mandatory.
Therefore, the user was upset and left.
What D needs is positioning, what is D? For whom?
Don't be greedy. As better C++, do a good job of better c++ , and as system programming, don't force GC.
Since metaprogramming is powerful, D should continue to maintain its advantages.
D can be positioned as serving for experts. Experts is minority. Why C++ user smaller than Python's, Ordinary users are much more than professional programmers.
D just need to position itself and experts will come naturally.