On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote:
> I.e. it isn't an issue of us D guys being dumb about the GC.

So you could say it's a design flaw of D, attempting to use a GC where it isn't suited?

>> If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too.
>
> With @nogc, you don't have to be careful about it. The compiler will let you know.

@nogc has issues integrating with features like delegates, but no one seems to care about that with statements like this. It's more convenient to not use @nogc than dealing with the hassles of using it.

On Thursday, 8 February 2018 at 17:32:53 UTC, ixid wrote:
> Do you really think sticking with the current course on GC would gain more users than very slightly changing tack and making it something you add to a simpler base? I think the second of those will gain more users.

No, the current course - which IS the optional GC story you're talking about - is not good. I'm saying change course by embracing our advantages instead of constantly playing defense.

D isn't going to beat Rust on compiler-enforced memory safety, so we shouldn't even play that game. Instead, pound them into the ground with our programmer productivity package. Destroy them with our familiar syntax that programmers already know.

On Thursday, 8 February 2018 at 23:50:29 UTC, Ali wrote:
> But D, unlike many other languages, promotes itself as primarily a system programming language

I think that's a mistake too. I'd rebrand it as a "general purpose" programming language. One language you can use everywhere. It worked for node.js and electron...

Though, of course, the GC is NOT a problem for those systems tasks. Even in the niches where it doesn't help, it doesn't actually hurt either. (in fact, the bigger problem we have in those niches are obligatory typeinfo generation and unnecessary bloat in the runtime.... implementation issues that Mike Franklin has made big progress on fixing already. and even those can be worked around, doing a serious system implementation is a bigger task than stubbing out a few functions.)

> https://en.wikipedia.org/wiki/System_programming_language

A few of those languages have GCs... and GC languages have been used for all these tasks before. It's not a dealbreaker.

On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote:

> What are D's limitations on do-it-yourself reference counting?

 * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting.
 * Much of Phobos probably wouldn't be compatible with DIY reference counting.

That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work.  But I haven't tried.

Also, I think Walter is currently working on getting reference counted exceptions into the language:  https://github.com/dlang/druntime/pull/1995

Mike

On Friday, 9 February 2018 at 01:31:41 UTC, Mike Franklin wrote:
> On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote:
>
>> What are D's limitations on do-it-yourself reference counting?
>
>  * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting.
>  * Much of Phobos probably wouldn't be compatible with DIY reference counting.
>
> That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work.  But I haven't tried.
>
> Also, I think Walter is currently working on getting reference counted exceptions into the language:  https://github.com/dlang/druntime/pull/1995
>
> Mike

Also, I think DIY reference counting is already done for us in the automem library https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/

Mike

On Friday, 9 February 2018 at 00:08:56 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 February 2018 at 23:50:29 UTC, Ali wrote:
>> But D, unlike many other languages, promotes itself as primarily a system programming language
>
> I think that's a mistake too. I'd rebrand it as a "general purpose" programming language. One language you can use everywhere. It worked for node.js and electron...

Plenty of "general purpose" programming languages. The issue being that very few offer classes, no GC, easy syntax, good tooling and editor support, ...

I noticed a trend with languages with so many going to functional programming or semi-class based.

From the outside D looks good but there are so many strange things in the D design, that just infuriate.

- GC ... sure, if only it did not allocate so much on startup. It makes any other languages look better, by simply having a lower memory footprint on first comparison.  C 0.1MB, C++ 0.2MB, Rust 0.4MB, D 1.4MB, ... Looks inefficient when its simply the whole 1MB allocation. But perception matters!


- import ... really, we are 2018 and people are still wasting our time to have standard libraries as imports. Its even more fun when you split, only to need import the array library.

Look how ridiculous C++ like "import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio;" some of the example on the front page look like.

I see people on Reddit sh*t all over PHP all the time and yet, its so darn easy and comfortable to not think about writing import all over the code, just to get default functionality!! Reddit is full of people who love to hate languages that simply work.


- Tooling. I will say it again and again until i die, it simply sucks for Windows users.

How fun is it to see dcd-server taking up between 90 to 120MB and seeing 10, 12, 15 instances loading into memory eating away 2GB memory.

Or seeing VSC work with some of the plugins for 5 minutes and then break again, forcing you to constantly restart VSC. Or how competing languages seem to provide more cleaner and better working plugins, with cleaner tool tips ( source documentation )

- Even the example on the front page are so typical "scare away the newbies". It looks like a cleaner version of C++.


D has always been a love/hate relationship for me. One can see the work that has gone into it but it feels like a Frankenstein's monster. Small details, big details, the lack of clear focus.

BetterC just moves resources away from actually implementing a permanent solution. Instead of maintain one system, you deal with two. While default D still deals with regressions and issue, BetterC being incomplete is pushed as the next big thing.

The library has design choices that date back a long time and nobody dares to touch. The whole constant GC debate is linked to those design choices. D can do a lot but the layer between both is so thin that at times you wonder if your dealing with compile or runtime features. CTFE or not. Talking about CTFE .. Stephan vanished for a long time busy with work and yet it feels reading the topics that very few people noticed him missing, despite working a year on the whole new CTFE engine. Not exactly motivating for people.

I can talk until i turn blue. I already wrote "a wall of text" as some say, in the Go topic and that was not even technical issues.

People talk about the need for a clear design focus, leadership and ... things go on as before. That is D in a nutshell. People doing what they want, whenever and things stay the same. New features ( that is always fun ), a few people doing to grunt work and all the rest comes down to people complaining because they see no reason to put effort into D, as it feels like a wast of time. << want to bet that this is the only thing people will quote, instead of the rest.

But on-topic again:

No GC, yay. Always a win because it makes a language stand out. Possible for D. NO! Too much design choices that limit the language. Another D3 rewrite will simply kill D.

D is so tiring. Its the main reason for going with Go, simply tired of waiting. In this one+ year time watching D, i have seen blogs, betterC half finished being promoted when D is already overloaded with features and has already a higher learning curve. More regressions and bug fix releases because the new features keep breaking stuff. Some more examples on the front pages. Some nice external packages that only limited amount of people care about. And very few things to improving the issues people mentioned the year before and the year before and the year before.

So again, why do people need to bother? The momentum D build up in 2016, seem to according tiobe really lost. I remember D hitting (23) 1% a year ago, now its ranking (29) 0.5%.

Great another wall of text at 2.50 in the morning. Frankly, i can write a book about D issues, justified or not. It will probably read like gibberish again and ... some people will cut parts to quote, complain ... but things will stay the same.

Everything feels so 90% finished, like the effort to finalyse things is always lacking. You see it everywhere in D. That is my view... disagree, fine but it does not change the outside perception of D. D needs a massive cleanup, a focus, probably a name change to get rid of the reputation...

D, D never changes ( fallout reference ).

On Thursday, February 08, 2018 23:57:45 Rubn via Digitalmars-d wrote:
> On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote:
> > I.e. it isn't an issue of us D guys being dumb about the GC.
>
> So you could say it's a design flaw of D, attempting to use a GC where it isn't suited?

You could say that, but many of us would not agree. Just because certain classes of GCs cannot be used with D does not mean that the fact that D has a GC built-in is not beneficial and ultimately a good design decision. Plenty of folks have been able to write very efficient code that uses D's GC. Obviously, there are use cases where it's better to avoid the GC, but for your average D program, the GC has been a fantastic asset.

- Jonathan M Davis

On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote:
>> That's been said over and over and the message has not gotten through.
>
> It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC".
>
> Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further!

"Death is nothing, but to live defeated and inglorious is to die daily."
 - Napoleon 'D' Bonaparte

Hey... logo idea for Munich 2018 -> Dman wearing a Napoleon hat - and riding a horse.

Hey.. it's better than Dman lying on a death bed, dying of a stomach ulcer...

I think we should have an annual D parade too...bring out all the might of D's machinery..and show the world how powerful we really are.

On Thu, 08 Feb 2018 17:08:41 +0000, bachmeier wrote:

> On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
> 
>> Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython).
> 
> I'm pretty sure CPython uses a mark-and-sweep GC together with reference counting.

It does. Originally it was reference-counting only, but they added the (generational) GC to clean up cyclic references. Because they do reference counting as well, you can disable the GC entirely.

https://docs.python.org/3.6/library/gc.html

On Friday, 9 February 2018 at 01:55:10 UTC, Benny wrote:
>
> People talk about the need for a clear design focus, leadership and ... things go on as before. That is D in a nutshell. People doing what they want, whenever and things stay the same. New features ( that is always fun ), a few people doing to grunt work and all the rest comes down to people complaining because they see no reason to put effort into D, as it feels like a wast of time. << want to bet that this is the only thing people will quote, instead of the rest.
>

D does NOT need a top-down, authoritarian, corporation like vision imposed on it (which would solve all the issues you mention).

D is an open source, meritocratic community of people, who drive the project forward.

Some (like you apparently) seem to think that a lack of authoritarianism puts D at a disadvantage - I simply disagree.

It may mean, that (some)things progress more slowly, and the overall vision is less certain - but that's exactly how I like it.

D 'emerges' from its community. It's is not imposed on its community.