This kind of thread seems to pop up once in a while in this forum. I read threads in this forum a lot more than i participate in the discussion but now I'll give my 2 cents. Don't take it too seriously.

Disclaimer: While I will write only negative aspects below, D is actually the language I like most from all I have tried (C, C++, C#, Swift, Python). It has it's quirks but other languages are also far from perfect.

1. Librarys:
- There are not a lot libraries and if you find one it will most probably not compile.

- If you find a working library the documentation is likely bad. You always hear the argument: "It's open source, you can help out writing documentation".
This is hilarious because if I want to write documentation for your library, I have to read and understand your code first. I will need 10-100x more time than the one who wrote the library.
The whole point of abstraction is that you abstract away the implementation. If i have to read your source to use your library it's just pointless.

2. It's too close to C++ to be worth the drawback:
- If you plan writing a serious long living project C++ is just a much safer choice.
Yes C++ looks ugly and D corrected a lot of bad design decisions, but both languages are still very similar. If you hold your nose and write C++ you will benefit from all the tooling and ecosystem.

3. Garbage Collector:
- If you can live with GC there are nice alternatives. Kotlin looks promising.
C# is also a really decent language in my opinion (and cross platform with .net 5).
A language compiling to native code with system level features and a GC is just a strange niche. You can turn of the GC but then you can't use all of the language anymore. I can't imagine a situation in which i really have to use a native language but want a GC...

On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:
clip
>
> 3. Garbage Collector:
> - If you can live with GC there are nice alternatives. Kotlin looks promising.
> C# is also a really decent language in my opinion (and cross platform with .net 5).
> A language compiling to native code with system level features and a GC is just a strange niche. You can turn of the GC but then you can't use all of the language anymore. I can't imagine a situation in which i really have to use a native language but want a GC...

Can you imagine a situation where you need to use a native language but don't want to use the GC?

On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:
>
> 3. Garbage Collector:
> - If you can live with GC there are nice alternatives. Kotlin looks promising.
> C# is also a really decent language in my opinion (and cross platform with .net 5).
> A language compiling to native code with system level features and a GC is just a strange niche. You can turn of the GC but then you can't use all of the language anymore. I can't imagine a situation in which i really have to use a native language but want a GC...

Maybe you specifically don't, but the US navy seem to be quite at home with it.

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet

"Given the need for predictable and reliable compliance with sub-millisecond timing constraints, Lockheed Martin evaluated a number of alternative approaches to real-time Java.  Ultimately, they chose to use the PTC Perc Ultra virtual machine (formerly called Aonix Perc Ultra), both in single-core and multi-core configurations. This technology adds real-time determinism to Standard Edition Java APIs by incorporating real-time garbage collection, fixed-priority real-time scheduling, prioritized queues and priority inheritance locks within the implementation of the virtual machine."

Just one example among others that I can point out for PTC and Aicas, which despite being JVMs, also support bare metal deployments for this kind of targets, thus as native as anything else that AOT compiles to native code with a language runtime.

Then there are these products:

Astrobe selling Oberon devkits for ARM, Cortex-M3, Cortex-M4, Cortex-M7 and now RISC-V, in business for about 20 years.

https://www.astrobe.com/Oberon.htm

F-Secure using their own Go port for secure firmware, among them their own computer on an USB key, USB Armory

https://www.f-secure.com/en/consulting/foundry/usb-armory

So there is a market, even if you personally don't care about it.

On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:
> A language compiling to native code with system level features and a GC is just a strange niche. You can turn of the GC but then you can't use all of the language anymore. I can't imagine a situation in which i really have to use a native language but want a GC...

A GC is useful for prototyping, but the problem with D is that there is no adequate model for ownership in the type system. It is not difficult to fix, you just need people to understand that multiple pointer types are needed and has to be agreed upon.

Until this happens the GC will continue to be problematic as you have to rely on ad hoc solutions with no real help from the type system. How do you gracefully transition code from GC managed to some other scheme?

Or you could add sanitizer mechanism and catch typing issues at runtime during testing.

But D needs something more than what is on the map. That is obvious.

On Wednesday, 4 November 2020 at 23:54:13 UTC, CraigDillabaugh wrote:
>
> Can you imagine a situation where you need to use a native language but don't want to use the GC?

Easy: Embedded, Realtime, HPC, some AAA Games

Yeah i know you can run Java or Python on uC, but 99% of embedded is native and no GC.

On Thursday, 5 November 2020 at 06:58:31 UTC, Paulo Pinto wrote:
> Just one example among others that I can point out for PTC and Aicas, which despite being JVMs, also support bare metal deployments for this kind of targets, thus as native as anything else that AOT compiles to native code with a language runtime.

Ok, there are ways to AOT JVM languages. My point was, if you can afford to use JVM you have nice alternatives to D. Also D's GC will by design never be as powerful as JVM GC. In D you can have pointers to manual memory, etc. This restricts the GC.

> Then there are these products:
>
> Astrobe selling Oberon devkits for ARM, Cortex-M3, Cortex-M4, Cortex-M7 and now RISC-V, in business for about 20 years.

I never even heard of someone programming in Oberon.

> https://www.astrobe.com/Oberon.htm
>
> F-Secure using their own Go port for secure firmware, among them their own computer on an USB key, USB Armory
>
> https://www.f-secure.com/en/consulting/foundry/usb-armory
>
> So there is a market, even if you personally don't care about it.

This is a imputation. I never said I don't care. All the things you mentioned are really niche. Because you somehow misunderstood my argument i will simplify it for you:
- When you can live with GC you can most of the time live with JVM or CLR. Then you have a lot good languages to choose from.
- If you can't live with JVM/CLR then you either have a very resource limited system or you really need every bit of performance. In this case you want a native language without GC.

Most of the time native language and GC is not the right combination.

On Monday, 12 October 2020 at 10:34:17 UTC, IGotD- wrote:
>
> Despite the popularity, the way I think is that with D I'm able to out compete people who would otherwise use C++ or similar. I can produce a solution faster which is also more stable.
+1

This is such an obviously transparent point and it's not made enough. I sometimes sit and think, I'm going to write library X in C++. A couple of days later I'm thinking, why am I wasting my time writing C++, when D is obviously the much better and more productive option, and much more pleasureable to write!? I park the C++ code and continue in D. I did this a few of times some time ago and now I don't bother with C++.

If D didn't exist, I'd be writing Nim, and if Nim didn't exist, I'd be writing Chapel or Rust before C++. I'm not even sure it's responsible to write C++ code anymore.

On Wed, 4 Nov 2020, 2:50 am frame via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:
> >
> > D is not present anywhere in languages to learn... Why?
> > (I get that it can be a chicken and egg problem)
> >
> > When looking for languages to learn, you have to start "somewhere".
> >
> > How do we make D part of this "somewhere"?
> >
> > Thanks
>
> I want to add my 2 cent as newbie:
>
> - For plain applications, D looks quite similiar to C++, C# but is less popular. It this a benefit?
>
> - It's likely that users need a library. This library may exists as D code but even the search for that library is not intuitive. You have to try multiple terms or browse manually for the library, this is bad. Also the library seems to be outdated while the C library developers just did a new release and you could assume the D-lib is just dead. This makes D look more like an experiment than a living standard.
>
> - The offical library reference is visually "unfriendly". For example, devdocs.io do a better job. On the D-site, it looks not well formatted. I am loosing focus while reading on some locations. The search engine is unsatisfying. Even that I can't format code in forums bothers me, because that are standard features and they just not there. This appears as "unfinished", we are not in year 1998.
>
> - D also needs a new modern, _just working_ IDE with syntax highlighting, formatting, autocomplete hints, quick documentation. I've tried the Dlang IDE, VisualD, WebFreak-D or other Plugins for Visual Studio and IDEA. Plugins either do not work well, get broken with never versions (eg. MonoDevelop) but also true for VS Code. You see quickly that event VisualD is just a plugin which is buggy, crashes and does not really integrate well (sepearate build options, passing arguments ignored, etc).
>

It sounds like you have used VisualD incorrectly.
It sounds to me like you did not use the D/VC++ project template, which is
msbuild native, and works extremely well. Maybe you used the old project
format from 5 years ago... I think that's still in there, but you shouldn't
use it today.
Look for the D/VC++ project wizard, and try your evaluation again.



Also realtime debugging is a pain, eg with VisualD: If you are
> lucky it will display the stack correctly - but it has problems with template functions and it show your structs in initial state rather actual value. I could not run the debugger in VS Code, it runs/breaks but shows nothing and it's not my job to report bugs to plugin-devs that just don't have the time to fix them. I could also only run partial debugging on IntelliJ IDEA since variables are not updated on change - there is always such an issue and the list goes on...
>
> Of course this is offtopic by the language itself but it has a heavy influence if I would try a new language which tools are only working on the command line out of the box. You may get the point, if you want to attract new users, you need a supported, working welcome packet just as an IDE with friendly features so the users can just start making experiences.
>
>
>
>

On Thursday, 5 November 2020 at 08:36:51 UTC, random wrote:
> On Thursday, 5 November 2020 at 06:58:31 UTC, Paulo Pinto wrote:
>> [...]
>
> Ok, there are ways to AOT JVM languages. My point was, if you can afford to use JVM you have nice alternatives to D. Also D's GC will by design never be as powerful as JVM GC. In D you can have pointers to manual memory, etc. This restricts the GC.
>
>> [...]
>
> I never even heard of someone programming in Oberon.
>
>> [...]
>
> This is a imputation. I never said I don't care. All the things you mentioned are really niche. Because you somehow misunderstood my argument i will simplify it for you:
> - When you can live with GC you can most of the time live with JVM or CLR. Then you have a lot good languages to choose from.

D is the only system language with GC I can deal with. I love the GC personally though. There's a significant difference between D with GC and Java with GC. The VM.

> - If you can't live with JVM/CLR then you either have a very resource limited system or you really need every bit of performance. In this case you want a native language without GC.

I don't think D is EVER going to be without a GC though. 8ts very necessary for app development... productivity and safe.

>
> Most of the time native language and GC is not the right combination.

Maybe you should look into not mixing up GC and nogc code.

On Friday, 6 November 2020 at 23:04:44 UTC, aberba wrote:
>
> I don't think D is EVER going to be without a GC though. 8ts very necessary for app development... productivity and safe.
>

D should take the same route as Nim. Nim has several garbage collection algorithms and can swap them out as they see fit. Latest reference counting algorithm has been a success for Nim and the language just keep on improving because they have invested in good GC as well an architecture where they can continue to play with different approaches.

GC is not bad but the language must support changing GC algorithms.

D is in a corner here a can go nowhere.