Is there an intention to 'finish' D2? (page 16)

On Friday, 26 November 2021 at 10:54:46 UTC, Dukc wrote:

Perhaps I used a bad word there. My point was that you're painting it as if only committed long-time users would give specific, helpful feedback and everyone else who bothers to give feedback would just be demanding changing everything at once.

Did I?

A 'la "D's GC is sad story, none will remain using it since C# has better GC and D can't do that so D should drop GC".

I think I've said that one should listen to what issues people have that make them reluctant to use D as a tool for their use case, but not necessarily adopt the solution they propose.

D's ecosystem is suffering because people are reluctant to go all in. They have fun with it for projects that are small in scope, but hesitate to do large things with it.

For instance, I started yesterday to fool around with Skia in order to make a simple application framework for my own use. I hold the option open for making it work with D, but it won't be a priority as long as there is no vision for D as a solution that is better than C++ across the board (for that use case).

Even an inexperienced user ought to recognize that the language isn't written just for them and the language maintainers can't satisfy everyone, but they have better chances to satisfy small, realistic requests.

It is possible for D to be an alternative for C++ for more users, but then adjustments have to be made on many issues. Not big changes, but adjustments to make it a clear improvement across the board over C++. Without that, D is perceived as somewhat different, and that is not enough.

November 27, 2021

Re: Is there an intention to 'finish' D2?

Posted by BoraxMan
in reply to Ola Fosheim Grøstad

Permalink

BoraxMan

Posted in reply to Ola Fosheim Grøstad

Permalink

On Friday, 19 November 2021 at 15:06:28 UTC, Ola Fosheim Grøstad wrote:

On Friday, 19 November 2021 at 14:05:17 UTC, Paul Backus wrote:

Part of the problem here, I think, is that people are more strongly motivated to speak up about their opinions when there is something they are unsatisfied with. So discussions like this will be biased towards the things people don't like about D, even if they are relatively happy with the language overall.

Actually, the biggest problem for the decision makers of D is that the average person who does use D from time to time never speaks up about what they are happy/unhappy with. So there is a big silent majority.

I didn't read the D forums for years. Random incident that I did. I only started to write here because Manu tried to argue for a direction that would make D better for systems development. So I wanted to back him. If Manu had not been persistent in his quest, then I'd probably would have put D back in the drawer for good.

It is of course possible to continue to make decisions based on the tiny hardcore that populate the forums, but then you won't have an ecosystem. And well, what is the point of having powerful meta-programming if there are no frameworks (except vibe.d) that are built with it?

Another "silent majority" here. I do some hobby programming, and while I like D the main barrier isn't the language but the way the language fits in with the OS (for me its Linux).

For D, there is this guide to packaging for Fedora
https://docs.fedoraproject.org/en-US/packaging-guidelines/D/
but it said that D doesn't support shared libraries and as an exception, static linking is OK. Is this even correct? It does answer my other question, should I link using GDC or LDC. Also, if I use DUB, how does that work? What is the process then?

This link implies you can create shared libraries
https://dlang.org/articles/dll-linux.html

Aside from the actual language, people are looking to see how the use of that language, the tools, fit in with the systems they are developing for. My choice of language isn't simply about the language, but how it builds actual distributed software. Best practices for how to create software.

For example, I've looked at Tilix, and noted that it uses libgtkd and LDC, and a dub.json file. It would be good to know the ins and outs, what you should do, what you shouldn't do, to say, make a Linux software package that can be built into a .DEB and .RPM. Can it be done if dub has to download dependencies? How to package?

It might seem trivial, but there are the little things that I think make a difference. I might write posts about this myself when I know that advice I'm giving is good advice.

On 27/11/2021 2:12 PM, BoraxMan wrote: > For D, there is this guide to packaging for Fedora > https://docs.fedoraproject.org/en-US/packaging-guidelines/D/ > but it said that D doesn't support shared libraries and as an exception, static linking is OK. Is this even correct? It does answer my other question, should I link using GDC or LDC. Also, if I use DUB, how does that work? What is the process then? It is completely out of date.

On Saturday, 27 November 2021 at 01:41:07 UTC, rikki cattermole wrote: > > On 27/11/2021 2:12 PM, BoraxMan wrote: >> For D, there is this guide to packaging for Fedora >> https://docs.fedoraproject.org/en-US/packaging-guidelines/D/ >> but it said that D doesn't support shared libraries and as an exception, static linking is OK. Is this even correct? It does answer my other question, should I link using GDC or LDC. Also, if I use DUB, how does that work? What is the process then? > > It is completely out of date. Yeah, it's dated 2010 and the package requires tango, so just a tad out of date.

Forums