February 09, 2018
On Thursday, 8 February 2018 at 23:27:25 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
>> Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection.
>
> Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker.

GC is all about time/space tradeoffs. That's all one can say about it really.

Yes, the 'ubiquity of it in the real world' (in popular and not so popular languages) suggest that most accept this tradeoff, in favour of using GC.

But many still don't..

And many that do, might decide otherwise in the future... cause I'm not sure how well GC really scales...(in the future, the size of the heap might be terabytes..or more).

That's not an argument for not defaulting to GC in D.

It's an argument for when GC in D, could be a deal breaker.

So it's good thing for the D community to consider these people as well - rather than saying 'who cares'.

In the end, GC just adds to all the other bloat that's associated with programming in the modern era. The more we can reduce bloat, the -betterD.

I'm glad there is alot of research in this area, and increasingly so - that's really important, cause the story of automatic memory management is far from over - even in D it seems.

February 09, 2018
> - 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.

Please explain what do you mean by it?
February 09, 2018
On Friday, 9 February 2018 at 01:36:02 UTC, Mike Franklin wrote:
> 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

We use std.typecons.RefCounted in many places in Phobos too.
There is only one big problem at the moment: it's not @safe and can only be @safe with DIP1000.
This is actually blocking a lot of work - think RCString, containers or even just a simple range which needs heap memory as state.
February 09, 2018
On Thursday, 8 February 2018 at 21:01:55 UTC, Walter Bright wrote:
>
> That really is an informative article, thanks. The only issue with it is that it doesn't cover the newer C++ ref counting model, which has proved popular.

Here is another very informative article, outling the 'tradeoff' between program 'throughput' and 'latency'.

https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/

The really important part of their conclusion, however, is that there is no such thing as a 'one size fits all' GC implementation:

.. " It is important to understand the underlying GC algorithm in order to decide whether it is appropriate for your use-case".

From this, I can only conclude that integrating GC too much into the core of the language & library can be problematic for many use cases, and not so for many others.

February 09, 2018
On Friday, 9 February 2018 at 01:55:10 UTC, Benny wrote:

> Plenty of "general purpose" programming languages. The issue being that very few offer classes, no GC, easy syntax, good tooling and editor support, ...
>
> [...]
>
> D, D never changes ( fallout reference ).

Hi Benny,
I have read both of your lengthy post and given your harsh criticism I decided to reply to you, even though I think in such cases that it's better to let the flame burn out by itself.

I totally respect your choice of using Go and your problem of usability on Windows.
On the other hand, I have yet to encounter the other issues you have mentioned (I don't want to belittle your considerations).

When I approached D, one year last august, I was instantly amazed by what I consider a clear and solid design.
What I appreciate as well is the bazaar style of development. I think it is worth it in the  long run because it allows D to take different directions that the ones original envisioned. One such example is the take on backend programming (vibe and the other frameworks). Go, Elm and Java (but many others) on the other end suffer because their "dictators" are  slow or against some paradigms (generics and structured programming are on example).

BetterC may seem an half effort that may split the development, but going in the past the D community is full of attempts that in the end succeeded.
The documentation is an example of that, or the way recently the @nogc story is evolving rapidly.

> 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.

I think the very opposite.
D for me come as intuitive as possible. With just a solid background on C and python I was able to understand the most important design decisions and write software more complex than before and build abstractions (Go goes in the opposite way).
Even reading code written by other seems easily accomplishable (something impossible for me in C++) and many design decisions don't seem half-assed attempts at innovate (like asyncio in Python).

I don't think that any of the abstractions of the std library or the idioms of the language add bloat and it seems to me that I can learn each one of them day after day without losing any sanity.

> 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...

That is my personal experience and I think that if you can be more specific and tackle some definite issues you may help this community.
February 09, 2018
On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
> On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
>> Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels.
>
> Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). Unless you mean garbage collection as in "not manual memory management"? But that still might not be as simple, because RAII would fall somewhere inbetween.

let's say python is supposed to offer slow execution. So, python doesn't prove reference counting is fast (even if it is possible in theory). D on the other hand provides binaries who are expected to execute fast.
February 09, 2018
On Friday, 9 February 2018 at 01:55:10 UTC, Benny wrote:
> 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:
> - 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.

It's easy enough to create std package like this:

module std;
public import std.algorithm;
//...

However, I'm a _huge_ fan of local imports and only importing what's needed. It helps with build times, binary sizes, and is a boon for finding where things are actually defined when DCD can't figure it out. And, of course, reduces namespace pollution.

Dependencies are usually bad. Imports are dependencies. Ergo...

Atila


February 09, 2018
On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote:
> On 2/8/2018 9:03 AM, Dave Jones wrote:
>> If D had a decent garbage collector it might be a more convincing argument.
>
> 'Decent' GC systems rely on the compiler emitting "write gates" around every assignment to a pointer. These are justified in languages like Java and Go for which everything is GC allocated, but they would be a performance disaster for a hybrid language like D.
>
> More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results.

When even you make excuses for the sub standard garbage collection how can anyone expect to use it as a positive selling point for D?

That's my point, that the current GC is not something that will sell many tickets to the show. Whether there are good reasons for it being so is kind of beside the point.


> I.e. it isn't an issue of us D guys being dumb about the GC.

I have no doubt about that.


>> 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.

I mean more mixing GCed and malloc memory. If you want to use malloc and still use language features that need GC, you still need to be aware and think about whether any of malloced stuff needs to be registered with the GC.

IE. It's not just a case of "hey just use malloc".




February 09, 2018
On Friday, 9 February 2018 at 14:11:37 UTC, Atila Neves wrote:
> On Friday, 9 February 2018 at 01:55:10 UTC, Benny wrote:
>> [...]
>
> It's easy enough to create std package like this:
>
> module std;
> public import std.algorithm;
> //...
>
> However, I'm a _huge_ fan of local imports and only importing what's needed. It helps with build times, binary sizes, and is a boon for finding where things are actually defined when DCD can't figure it out. And, of course, reduces namespace pollution.
>
> Dependencies are usually bad. Imports are dependencies. Ergo...
>
> Atila


FYI: and for the lazy ones, there will hopefully be std.experimental.scripting soon:

https://github.com/dlang/phobos/pull/5916
February 09, 2018
On Friday, 9 February 2018 at 16:54:35 UTC, Seb wrote:
>
>
> FYI: and for the lazy ones, there will hopefully be std.experimental.scripting soon:
>
> https://github.com/dlang/phobos/pull/5916

Why not make this a package.d file for std?