https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
> First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.
>
> [...]

This is a pretty well thought out post. Are we getting forward?

On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:
> https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org
>
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.
>>
>> [...]
>
> This is a pretty well thought out post. Are we getting forward?


Quote from that post:

"""
D has a nice community IF you fit into the mold. As a Windows user i am frankly fed up with people giving responses as "report it, fix it yourself" when it has been clearly stated that i do as much.
"""

Sadly it's very true, and I actually have tried to fix the two RPC issues that I reported (https://forum.dlang.org/thread/ompyepvaeeorbldfyjkd@forum.dlang.org)

But I am not a complier guy or network guy, I was not able to fixed them myself, so my project using D stalled.

I think that is the same experience for many people who just want to use D develop applications: many needed component libraries are simply not working. (In 2021, who can live without a network / RPC library?)

On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:
> https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org
>
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.
>>
>> [...]
>
> This is a pretty well thought out post. Are we getting forward?

I had an experience where (because I'm not a network programmer, and the situation was time sensitive) I opted to use a Rust solution rather than Vibe.d which I tried but found unsuitable. It frustrated me because I know D can do a great job in this sphere - but I wasn't in a position to do anything about it.

One thing about languages such as Rust and Go is that lots of people in their ecosystem have an internet/network programming background. So you're likely to find decent server/client libraries, and there isn't just one option for a HTTP library, but there might be three, four, or more relatively high quality libraries. In addition because of the nature of their communities, if the "flagship" solution was for any reason to become unsuitable, someone would immediately write a great replacement.

A lot of issues like this in the D space will be greatly ameliorated and some will be eliminated altogether once ImportC is made to work robustly. It won't be a "panacea" but it will help immeasurably. In that situation, you'd just dial up a C library and call it from D. You'd be able to lean on C libraries for the tools you need and write D code for the stuff I want to build. Bootstrapping from C in this way is the key to resolve this issue.

On Sunday, 7 November 2021 at 21:39:55 UTC, data pulverizer wrote:
> A lot of issues like this in the D space will be greatly ameliorated and some will be eliminated altogether once ImportC is made to work robustly. It won't be a "panacea" but it will help immeasurably. In that situation, you'd just dial up a C library and call it from D. You'd be able to lean on C libraries for the tools you need and write D code for the stuff I want to build. Bootstrapping from C in this way is the key to resolve this issue.

I don't know if using C (or C++) frameworks will provide an acceptable programming experience. C frameworks tend to be quite distant from what you would expect from a higher level language like D. You would have to modify the C framework's «runtime», like making it create treads using the D runtime, etc.

On Sunday, 7 November 2021 at 21:39:55 UTC, data pulverizer wrote:
> On Sunday, 7 November 2021 at 11:43:23 UTC, Imperatorn wrote:
>> https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org
>>
>> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>>> [...]
>>
>> This is a pretty well thought out post. Are we getting forward?
>
> I had an experience where (because I'm not a network programmer, and the situation was time sensitive) I opted to use a Rust solution rather than Vibe.d which I tried but found unsuitable. It frustrated me because I know D can do a great job in this sphere - but I wasn't in a position to do anything about it.
>
> One thing about languages such as Rust and Go is that lots of people in their ecosystem have an internet/network programming background. So you're likely to find decent server/client libraries, and there isn't just one option for a HTTP library, but there might be three, four, or more relatively high quality libraries. In addition because of the nature of their communities, if the "flagship" solution was for any reason to become unsuitable, someone would immediately write a great replacement.
>
> A lot of issues like this in the D space will be greatly ameliorated and some will be eliminated altogether once ImportC is made to work robustly. It won't be a "panacea" but it will help immeasurably. In that situation, you'd just dial up a C library and call it from D. You'd be able to lean on C libraries for the tools you need and write D code for the stuff I want to build. Bootstrapping from C in this way is the key to resolve this issue.

Yeah, I still have hope. I also see much happening in D now. There are forces wanting it to succeed. But we need to focus.

Most important thing I need rn (I know ppl find it silly, but coming from other languages you get so used to it) is a reliable and good IDE with static analysis, autocomplete, goto definition that just works and built in package management and a good set of core libraries that are rock solid.

Then I can use D at work for some projects (instead of C#), which is my goal. (We have some devices where we barely have space left for dotnet runtime)

On 08/11/2021 11:30 AM, Imperatorn wrote:
> Most important thing I need rn (I know ppl find it silly, but coming from other languages you get so used to it) is a reliable and good IDE with static analysis, autocomplete, goto definition that just works and built in package management and a good set of core libraries that are rock solid.

As of late, when I try goto definition with DCD it works fine.

But the future of DCD is to be rewritten to use dmd-fe.

I did say this on Discord earlier today, that I'm hoping someone steps up to do the rewrite (really its a refactor + addition of the extra engine).

But in saying that, this stuff should be owned by the compiler developers. They are the ones that are going to make the IDE integration actually good.

On Sunday, 7 November 2021 at 22:30:30 UTC, Imperatorn wrote:
> Most important thing I need rn (I know ppl find it silly, but coming from other languages you get so used to it) is a reliable and good IDE with static analysis, autocomplete

++1 I think IDE experience I've had in VS Code in a language like Rust is frankly awesome and D's was quite poor and frankly enough to put new people off the language. Sorry but that was my experience. I now just use C++ syntax highlighting and the terminal, but it's some time since I used the D plugin so I might try it again.

> .. and built in package management and a good set of core libraries that are rock solid.
>

Honestly, I think the standard library is getting better. From a looking to get work done perspective it's certainly much better than before. Improvements are of course necessary, but I wouldn't say that things are bad at all, but then I'm not from the DotNet world. I compare it to things like Julia, Nim, Rust, Chapel and so on, and I'd say D compares very well indeed.