On Thursday, 26 November 2020 at 18:27:25 UTC, Jacob Carlborg wrote:
> Yes. C++20 got support for coroutines, which also means support in LLVM.

Interestingly they chose to not implement a ready-made version of coroutines, but the building blocks to do so. At least that is my understanding. Looks intriguing. It will be interesting to see what kind of libraries people build with it.

...
I already raised similar sentiments. There are lot of posts where community is asking the D maintainers. They might not be interested and keep silent. I wonder why
a. why other upcoming langugages like crystal/nim/even zig has more contributors.(i meant they are good languages but they are more welcoming and have more news)
b. I thought after walter's talk on memory corruption, there will be a big buzz on D as a safe and easy alternative to rust. I didnt see a single post on HN/reddit.
c. AFAIK the fastest file system in world is written in D. Isnt this enought for everyone to convince(am not sure if its a mix of c++ and D).
d. I wish andrei/walter/others bring the community together and create a goal.
e. There is no other way other than challenging Rust/Go with features and benchmarks. Since we dont have corporate funds, we have to do haka dance. I wonder why Facebook didnt adopt it more when Andrei was there. Not sure what all issues they saw.
There is lot of selflishness here. I cant wait for 15-20m of build for every single line of C++ code change I make. I want a better language. Hope the maintainers come out of their feature parity race, frog in well attitude and make D a big success. Without community there is nothing. You can have a dogmatic goal like go, but you need one. Hope I dont have to start liking rust.

https://forum.dlang.org/thread/wkzwturzlnnhfpuplyrr@forum.dlang.org

On Thursday, 26 November 2020 at 19:17:25 UTC, JohnT wrote:
> d. I wish andrei/walter/others bring the community together and create a goal.

I think it would be better if the goals come from the community, bottom up builds a better social fabric. If it is top down everything falls on one person, and that is not as efficient.

Could be ARC, could be async/await, but it has to be something that can be completed within 6 months. Too ambitious goals tend to fizzle out,


> e. There is no other way other than challenging Rust/Go with features and benchmark

The better way is to find goals that are different from Rust/Go.

>
> The better way is to find goals that are different from Rust/Go.

Yes I agree. Atleast they come up with defined goals. Not sure if Andrei itself is actively involved. Btw, why cant weka sponsor D. They seem to be making money.
Whether D suceeds or not thats not in our hands, but we should do everything to make it possible.

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why?share=1

On Thursday, 26 November 2020 at 20:21:21 UTC, JohnT wrote:
> Yes I agree. Atleast they come up with defined goals. Not sure if Andrei itself is actively involved. Btw, why cant weka sponsor D. They seem to be making money.
> Whether D suceeds or not thats not in our hands, but we should do everything to make it d .
>
> https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why?share=1

I don't really think being a replacement language should be a goal, people generally just look for the best option for a specific use case. But there seems to be some motion towards being better for soft realtime. So basically, build consensus around that, and identify the missing pieces...

On Thursday, 26 November 2020 at 21:04:05 UTC, Ola Fosheim Grostad wrote:
> I don't really think being a replacement language should be a goal, people generally just look for the best option for a specific use case. But there seems to be some motion towards being better for soft realtime. So basically, build consensus around that, and identify the missing pieces...

Also, remove outdated stuff. Like, don't link to abandonware from dlang.org, it gives a graveyard feeling. Are anyone dveloping Dash? It is listed as games sofware that use D.

On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:
> Whether a programming language can be popular depends on what?
>
> I think there are two important points, that is, killing skills and availability. At the same time pay attention to shortcomings.
>
> I'll talk about my opinion today.
>
>
> ## D
> Must kill skill: It looks good?

It has four main advantages:

- Metaprogramming. In C/C++ you're limited to what the precompiler can do, but D's metaprogramming capabilities are almost other worldly, save for a few small stuff. D currently doesn't have metaprogramming support for attributes, which could solve the issue of attribute hell, especially with containers.
- Fast compile times with the performance of C/C++. Even with DMD and using the GC, it not only outclasses most scripting languages, but while compiling faster than C/C++. Once someone takes the time to optimize the D code by reducing GC use and using some compiler that has better optimization like LDC, it becomes nearly indistinguishable from C/C++. This, alongside its super-easy interoperability with other languages, makes the language a good candidate for a low-level scripting language.
- Interoperability. It's mostly binary compatible with C and C++, almost seamlessly can load their libraries, etc. I don't know what's the current state of D's DLL support, if anything this is a point where it must get better. D's main advantage should be either integration into other projects, or integrating preexisting ones into a D project.
- Multiple supported paradigms. Single paradigm programming is a pitfall, which leads to forcing the same solution to every problem, which in turn will lead to over-complicated codes, like how "enterprise" devs often do object orientation on everything. While functional programming is very promising, in itself can't solve all the programming problems, and can lead to performance issues from frequent data copying.

> Availability: standard library is poor.

It actually starts to get better, and since the language easily interoperates with others, anybody can port C or C++ headers to D. My current gripe is the mediocre XML support currently on D. The current one in the standard library

> Bad IDE.

It's okayish, but there's a lot of potential to growth.
- For the code-d team: Do something about the lack of refactoring support! It's super annoying to rename each thing individually, since VSCode's "change all" feature is too overboard and only works within a single file.
- For the Visual-D team: Please, add some integrated dub support! It's the default package manager of D, and without it you're destined to deal with dependency hell.

Due to the sheer power of the metaprogramming feature, any IDE plugin must at one point integrate the DMD frontend. That's probably the only way to get the whole metaprogramming fully cooperating with IDEs.

> GC efficiency is low.

Not anymore, as the GC is now multi-threaded. `@nogc` and `nothrow` attributes are must haves at functions that are time-critical and where they're applicable. Reducing memory allocations is a good practice, no `malloc` will speed up your application if you need to allocate memory thousands of times in a short time, while you could work on the same preallocated memory location.

> Lack of friendly debugging tracking tools.

Visual Studio works well as a debugger, but memory access violations are a bit hard to trace down sometimes. Breakpoints do work however.

> Lack of pprof and other practical tools.

It is in a dire need of a GUI editing tool, but I've made one for my own graphics engine. I'm planning on making another one, might be a VSCode plugin, if not it'll be a standalone app. That will be a pretty big breakthrough, however I don't know yet what GUI framework should I target. Maybe I can even add D export functions to a preexisting one.

> ## Summary
> D language must improve usability if it is to become popular!

D must become even stronger in fields it's already strong, and the community must fix the stuff where it's currently weaker. I've outsourced many of the components of my game engine to external libraries, both to allow easier unit testing (which ultimately killed the integrated collections - it was quite difficult) and to allow others to use them. Currently most of D's issues can be traced back to a weaker community, but this is slowly changing.

On Thursday, 26 November 2020 at 18:27:25 UTC, Jacob Carlborg wrote:
> That varies between implementations. You can either do single threading. Or have multiple threads (as many as the computer has cores) with one event loop per thread. Each async function can only be executed on a single thread. Or multiple threads with a single event loop and the async functions can run on multiple threads. That is, run on one thread, be suspended and be resumed on another thread.

Ok Jacob, so I got this idea: maybe it would be possible to have something like await as a gateway for temporary sharing of memory? Basically a multithreaded version of scope?

Just an idle thought, but maybe D could do something interesting with it.

On Thursday, 26 November 2020 at 15:27:22 UTC, rikki cattermole wrote:
> On 27/11/2020 3:45 AM, IGotD- wrote:
>> On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim Grostad wrote:
>>>
>>> I dont think this is the case. You are just reading the general forum and not the learn forum :).
>> 
>> I read both but the activity in the learn forum is pretty low.
>
> Of the many places I monitor for questions, Discord is the most active.

That's due to the kind of people olin the Discord vs the Dlang Slack...the discord is like Macau...if you know what I mean 😜

On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:
> Whether a programming language can be popular depends on what?

>
> ## D
> Must kill skill: It looks good?
> Availability: standard library is poor. Bad IDE. GC efficiency is low. Lack of friendly debugging tracking tools. Lack of pprof and other practical tools. Although the language features many but can not add popular practical features, such as await.
>

>
> ## Summary
> D language must improve usability if it is to become popular!

Its soo funny though 😂. D be like "Why you do me that?"


Personally I think D is great for most stuff... I can't personally point anything blocking my use case for D at its current state (not to say that things shouldn't be improved)... except embedded programming which is being worked on.


You can to look at the community from these three:


1. The C/C++/?? veterans. They know their stuff and tooling. They most likely use emacs or vim and are happy with pointing Cli tools like gdb at the binary to debug stuff. It so happens that most of the core contributors belong in this group. To them, work on the compiler, memory safety, nogc, technical correctness, deep metaprogramming wizardry, and related areas are more important. They're not the type to develop dub packages or ecosystem tools (motivation??)...and might not know how even if they want to...cus they don't use those tools. They're not the people to write D blog posts, articles, videos, or appear in podcasts, etc. They are not?? the community "cheer leaders". Remember, they're the core contributors and very short of manpower because D is a large language with many new ideas. One reason why they might be under staffed could be how its not easy to contribute to D due to the unpolished and undocumented process, workflow, project direction, etc. They're very technical but not enough time (or motivation) to do those soft tasks. If you read some of the phobos docs, you'll understand they're the folks doing the work.


2. Is the intermediate. They're the folks who can move between 1 and attend to 3. They answer most of the technical questions cus they have come to know where to find what. My guess is there's not a lot of such people...or at least enough active in the community day by day. And they're probably working so their free time isn't enough to do more. They're the contributors of most packages on dub... bindings, ports, etc. They may not be core contributors but they contribute to the core language too. They're generalist. Not enough time means undocumented packages??

3. Is the rest... coming from JavaScript, Java, python, etc where the ecosystem is effortlessly polished... mostly. They're used to IDEs, packages, tutorials, videos, great docs (those that don't read like memory dump of implementation details), example projects,... that kind of stuff. They sometimes find it hard to settle with the absence certain tools or under-development or maybe unique position?? of D ecosystem like they're used to. They're hooked by how nice D code feels and can't accept why D isn't all hot and popular..HN, reddit and stuff. They may feel like D needs more marketing, promotion and stuff. Or that D needs needs x&y features which has made T lang popular. Popularity can mean more users (including engineers from other companies who might fund D or offer developer time), more contributors, more packages, improved docs, more tools, etc.


Of course its not a perfect categorization cus the community is more diverse than that. But that's some observations I've made. Also, there are so many people also using D quietly.