On Friday, 6 October 2017 at 17:14:51 UTC, Rion wrote:
> https://www.quora.com/What-is-your-review-of-D-programming-language
>
> It seems that D still has the GC being mentioned up to today.
>
> Maybe its better to move the standard library slower to a non gc version in the future...

I think there is some merit criticizing D's GC.

The major problem with it ATM is that there is no convenient way to use all (most) of D's std lib without it.

This also extends to third party libs - most of them are coded with the GC in mind because of the above point.

I'm more an ambivalent person re. the GC - I see it as an useful tool most of the times, but also would like to get rid of it cleanly when circumstances require it.

I think there are some great steps already done to make it easier for programmers to use D without the GC: @nogc, betterC and the gang, but D is not yet up there.

Not for the naysayers sake - there will always be plenty of them regardless, I think more focused work on finishing the bellow points will make pragmatic D programmers more productive:

- Scope (-dip1000), a great tool to help code safe manual memory managed style apps. This could be huge for attracting more system level guys to D once it is finished (see bugzilla), it could offer some of Rust's guarantees without resorting to mind bending techniques - all in a nice C like syntax.

- betterC, this one is nice as it enforces "cost free abstractions" bondage while providing a low level C compatibility, more work here on RAII will be a boost! In general the work done for betterC for reducing bloat and impose a "pay-as-you-go" discipline will help D in general.

- Allocators - right now they are in Phobos... This is not great, they should be split in 2 parts: core an druntime. One should be able to use a minimal set in betterC mode, and the full version with druntime (all GC related parts).

All the above are cascading on each other, and the sum will create a hard to refuse offer even for the most dye-hard C/C++ guys.

And lastly, Ds GC needs work - it is not yet optimally implemented (see http://forum.dlang.org/thread/ewdoqmvslcnypzyrbfwz@forum.dlang.org) not to mention that design wise there are still more things to explore and experiment with: precision scanning, determinism, and a lot of research done on system-level GCs yet to consider.

On Friday, 6 October 2017 at 18:09:58 UTC, Ali wrote:
> On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
>> On Fri, Oct 06, 2017 at 05:14:51PM +0000, Rion via Digitalmars-d wrote:
>>> https://www.quora.com/What-is-your-review-of-D-programming-language
>>> 
>>> It seems that D still has the GC being mentioned up to today.
>>> 
>>> Maybe its better to move the standard library slower to a non gc version in the future...
>>
>> Why is GC a problem?
>>
>>
>> T
>
> The reputation is D's GC is slow, and Manual Memory Management is fast

Actually, Manual Memory Management is slow and D's GC is slower.

But IMO that kind of means GC isn't that big of a problem in D. Because, if malloc/free is slow (free is often slower), you want to avoid them as much as possible. You do this by reusing your memory/buffers. Which means that even if they are GC allocated buffers, they aren't collected and you are not allocating new buffers (often) after initial allocs, so the GC doesn't even run.

There was a good talk in cppcon2016 that gives you an example what high perf AAA games do for memory allocation. The presenter explains how they reduced memory allocations from 300 000 to 3000 (https://youtu.be/tD4xRNB0M_Q?t=1200).

On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user wrote:
> Actually, Manual Memory Management is slow and D's GC is slower.

Allocators should not work without an internal state. The fact that the heap chunk you get is mallocated or gcallocated shouldn't be a concern. The data structure can still use internal policies about how to request memory.

At the same time with allocators it's another problem. I'd say that the old-fashioned strategies shouldn't slow down the growing, even if the memory provider is better.
I don't know if you understand what i mean but in short:

    Appender!(SpecializedAllocator, int[])

shouldn't be slowest than

    Appender!(int[])

despite of the internal tweak that already exist. With allocators the situation is a bit confuse: who does provide the improvement ?

On 10/7/2017 1:16 AM, AB wrote:
> Do you know why I'm not using D right now? Because I'm already invested in C++. Also I can get a prebuilt C++14 compiler running on a Jurassic-dated FreeDOS;

DMC++ will still generate code for DOS, and I test it regularly. The compiler itself won't run on DOS, because DOS doesn't have enough memory. But as a cross compiler, it works fine.

16 bit C++, however, must be subsetted to work on 16 bits - exception handling and RTTI won't work (not enough memory).

You can use a 32 bit DOS extender, though.

I'm curious what C++14 compiler runs under DOS. The only C++ compilers I'm aware of that run under DOS are very old, pre-C++98, ones.

> meanwhile you've abandoned Windows XP.

dmd still works on and compiles for XP, it just officially is not supported on it. The problem with XP is its dodgy support for DLLs and thread local storage. This is an operating system problem. Officially, we want to support the entire language, not a subset.

> Where D doesn't tread, C++ persists unchallenged. What will happen when Microsoft drops Windows 7, are you going to drop it too?

D compilers being Open Source means that anyone can support whatever platform they need to.


> So what can you do now, other than abandon all hope? You could standardize D ("ISO/IEC DLANG:2020"), officially endorse and support an "official" **standalone** IDE for it (so that it won't be a one-man two-user project), and cross your fingers hoping that C++ will run out of steam before D does.

D doesn't have to destroy C++ in order to be quite successful.

On Saturday, 7 October 2017 at 18:31:46 UTC, user1234 wrote:
> On Saturday, 7 October 2017 at 15:12:08 UTC, Random D user wrote:
>> Actually, Manual Memory Management is slow and D's GC is slower.
>
> Allocators should not work without an internal state.

Damn...I meant the opposite, Allocators should work without an internal state.

On 10/6/2017 1:39 PM, Laeeth Isharc wrote:
> Perception is so important when people are making decisions about something they don't know.  (As Walter says, you have to write tens of sloc in a language to really see it's benefits.  They won't be so evident if you write D like the languages you know).

I've nearly finished converting the Digital Mars C++ front end from C++ to D. Amusingly, it looks line-for-line almost identical to C++ (the biggest change being exchanging "->" for "."). But I deliberately made as few changes as possible, because if I introduce a bug doing that, it will be much easier to find by comparing the C++ source with the D source.

To aid in this, I do it function-by-function, running the test suite after each function is converted. The idea is to use `git bisect` to isolate any conversion bugs not covered by the test suite.

So the end result has all the flaws of the C++ version. But once in D, I can start taking advantage of D (like nested functions) to structurally improve it. It'll always show its C++ inheritance, though.


> So I think the GC series has been very helpful.
> 
> But it might also be helpful to be very explicit on the functions that can and can't be called with nogc (I mean a top level overview in the docs) because it's one of the remaining sources of FUD that people say "yeah but you can't use large parts of the standard library without the GC".
> 
> And for things that are useful and easiest done with GC it would be nice to have an alternative that doesn't depend on the GC - if for no other reason than to address objections.  So the answer is then "yes - you're right, these X functions depend on the GC, but there are similar ones that don't".  (Walter already started that for functions that use the GC for purely legacy reasons but I mean for more difficult cases too.  I know Weka wrote their own versions of some std.algorithm functions for example).  Many things aren't much work, but when you have a lot to do, even small frictions can have big consequences.
> 
> So it's also a documentation question - it's not that easy from the outside last time I looked to see just how easy std.experimental.allocator is to use.

One of the motivations for -betterC is to make D usable without any reliance whatsoever on the D runtime library, including the GC. You still get a long list of benefits from using D over C++. (The translation above is relying on -betterC.)

On Saturday, 7 October 2017 at 05:19:21 UTC, Adam Wilson wrote:
> I saw we ditch the lot and focus on the large languages where D can get some traction (C#/Java).

I don't see a chance to attack C# unless Microsoft officially adopts D.

Java is facing some uncertainty at the moment. The Java 9 module feature (Jigsaw) was forced against community/committee consensus. Oracle seems to let go (See EE4J). Java people are fine with GC, but really care for their IDE and D is lacking there.

With respect to GC, I consider performance a red herring. Everybody who really cares for performance has enough possibilities in D to achieve it. My short answer wrt D and GC is "It is not really an issue" which admittedly does not sound very convincing. There is a long answer which is basically the article series in the D blog and I believe it is convincing enough. People looking for a short convincing answer are just chasing some hype, ignore them.

I see opportunities for D in the web backend world. Microservices and serverless architectures make it (relatively) easy to introduce new languages. D needs more framework stuff for "easy and quick" microservices. D needs better IDE support, for example in hipster editors like VSCode.

I see opportunities for D in the embedded world. The people who try to use Java for embedded would be served very well with D. Crosscompiling and architecture support needs improvement though. I recently heard some praise for Go, which allegedly makes it easier than C or Rust.

I'm not sure about performance critical stuff. Maybe marketing C++-integration more could be helpful to get the people who rely on stuff like OpenCV, are forced to use C++ and dream about something better. We are fighting the C++ renaissance cool-aid, though. C++21 will surely solve all problems...

On Saturday, 7 October 2017 at 09:37:12 UTC, Radu wrote:
> I think there is some merit criticizing D's GC.
>
> The major problem with it ATM is that there is no convenient way to use all (most) of D's std lib without it.
>
> This also extends to third party libs - most of them are coded with the GC in mind because of the above point.

I guess a non-GC solution for throw new Exception will help with quite a lot.  What to do about the rest (at least for Phobos)?

> - Allocators - right now they are in Phobos... This is not great, they should be split in 2 parts: core an druntime. One should be able to use a minimal set in betterC mode, and the full version with druntime (all GC related parts).

Would it make sense to have a BetterC version define for Phobos?  Or is this a terrible idea?  So you could still use some subset of Phobos from BetterC mode, and maybe this subset could be expanded over time?  And maybe people would write a complimentary set of functions to cover the missing most useful things in a way that doesn't depend on the runtime?

It makes sense what you say about allocators - it would be nice to be able to write BetterC code using those.  I used dscanner quickly to see what the imports are, and I wonder how much work it would be to do what you propose.

core.atomic
core.bitop
core.exception
core.internal.spinlock
core.memory
core.stdc.errno
core.stdc.stdlib
core.stdc.string
core.sys.posix.pthread
core.sys.posix.sys.mman
core.sys.windows.unknwn
core.sys.windows.windows
core.thread
std.algorithm.comparison
std.algorithm.iteration
std.algorithm.mutation
std.algorithm.searching
std.algorithm.sorting
std.array
std.c.stdlib
std.c.string
std.concurrency
std.conv
std.exceptionstd.file
std.format
std.internal.test.dummyrange
std.math
std.meta
std.random
std.range
std.range.primitives
std.stdio
std.traits
std.typecons

On Saturday, 7 October 2017 at 20:36:24 UTC, Laeeth Isharc wrote:
> Would it make sense to have a BetterC version define for Phobos?

Quite a lot of Phobos already works that way.

I think the GC discussion think will never go away because of the amount of c++ coders that come here.

If you want to flee from C++ you have two realistic options: Rust and D.

When you are looking at D and comparing metaprogramming, traits, ranges, UFCS, etc, its amazing: 'SO MUCH better than C++, i'ĺl leave right now!'

BUT then there is GC. And its not only about performance. You are programming at 5 10, 15 years with manual memory management, you lived the your entire live under the law of "you will not pay for what you don't use". Then you have to accept that you have a GC doing things under the hood. Even if you understand whats going on (and thanks the GC series for that :)), its a difficult paradigm shift.

I never had problems with GC, and im fine programming with it, but there is a c++ ghost in my ear every time speaking about manual management ;P

But im so used to D now that everytime I look back at c++ it give me chills. and BetterC and noGC libs are coming, so I think there is a ever brighter future ahead :)