On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc wrote:
> On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote:
>> But as a C++ developer, I can tell you that : D's GC is what prevents me to use it for my current C++ programming tasks.
>>
>> Because I can perfectly live with a GC that progressively collects bits of memory in a predefined amount of time, like in the Nim language, but not one that can pause my application for an unpredictable amount of time.
>>
>> That's just my personal case and opinion, but I don't think I'm the only C++ programmer on the planet to dislike D's GC for typical C++ development cases, which are generally those where the lack of a GC is the reason that lead to the use of C++.
>
> Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?

In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D.

So that's not worth the effort, if I can't use D's powerful standard library as usual.

I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time.

In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...

On Monday, 16 October 2017 at 02:10:31 UTC, Jerry wrote:
> On Sunday, 15 October 2017 at 16:29:22 UTC, Ecstatic Coder wrote:
>>>> If all that is already available, perfect :)
>>> [snip]
>>>> And moreover I'd be delighted to start using D instead of Go for my next web server developments.
>>>
>>> You can start now and get performance later? In fact you may supply important benchmarks from your day to day usage.
>>
>> Ok. Still not convinced to use D instead of C++ for my personal use cases (games and other soft real-time apps), but I get the idea.
>
> I switched my personal game to D from C++. Was easy, most of it was just copy paste. I was writing a math library to replace the one I was using to make it a bit more light way and to fit my needs a bit more. I didn't like how some thing were implemented in the library I was using. So I started with templates, I need multiple types and what not for the same purpose. At some point I have a function that needs to take 2 different template types.
> It starts to get so convoluted, order matters cause C++ still just uses copy-paste-includes and I don't think modules made it into C++17. I wrote the same library in half the code, in a way that's more readable and manageable. I didn't have to define things so that they would work, I could define them logically the way I'd expect them to be. Mixins also reduced code quite a bit, generating functions for different types and dimensions. Even though you have constexpr if statements now you still need to define all the function bodies even if they all can go in one function body now.

Thanks for sharing your experience !

From https://wiki.dlang.org/Vision/2017H2:

2. @nogc: Use of D without a garbage collector, most likely by using reference counting and related methods Unique/Weak references) for reclamation of resources. This task is made challenging by the safety requirement.

Eventually it will come (I hope) :)

I'm on the game programming in D train also.

And its a bless comparing to C++, but I have the same concerns about the impredictable GC pause time.

On Monday, 16 October 2017 at 05:20:16 UTC, Dmitry Olshansky wrote:
> On Sunday, 15 October 2017 at 20:24:02 UTC, Adam Wilson wrote:
>>>> database access (MySQL, PostgreSQL, Aerospike) libraries are available,
>>>
>>> That is important actually.
>>>
>>
>> So important that it should be a Priority 0 Must Have.
>
> Luckily it should also be quite strightforward to write them. At minimum there would be a C, Go, Java and Python “driver” to look at.
>
> Also surprisingly, D has superior driver for MySQL that talks native binary protocol while most other languages use the text mode.
>
>>>> preferably as a standard library (like in Dart and Go).
>>>
>>> Can’t do that. And it’s not standard in Go and Dart but packages, dub
>>> should work for that.
>>>
>>
>> I've been thinking about this question a LOT, and I'm not convinced it's impossible to put the DB libs into the standard
>
> Problem is - the development of std has glacial pace. Even if you put say Aerospike in std, I don’t think it’s in our best interest to have stagnated DB libs. DBs add features and ship new versions all the time.
>
> What might work is JDBC style approach - having a common interface in std with implementations in 3rd party. SQL might work this way.
>
> NoSQL though is highly irregular and benefits primarily from features unique to a particular vendor.

This is the best answer I've even been given on the main drawback of a standard library component.

Then I suggest that some script is used which "standardizes" the module component of a thirdparty library to make it belong to the "std" namespace, and put the result in the DMD/GDC/LDC installation packages.

Best of both worlds...

On Monday, 16 October 2017 at 09:58:46 UTC, Ecstatic Coder wrote:
> On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc wrote:
>> On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote:
>>> [...]
>>
>> Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
>
> In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D.
>
> So that's not worth the effort, if I can't use D's powerful standard library as usual.
>
> I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time.
>
> In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...

A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.

Have you tried using a @nogc main loop in your programs/games? I'm curious to learn why that might not have worked for you.

Atila

On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
> A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.

I don't use shared_ptr much, but why would a single shared_ptr be that slow?

On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
>> A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.
>
> I don't use shared_ptr much, but why would a single shared_ptr be that slow?

Cascade deletion of nested data structures, with the possibility of causing stack overflow.

Nicely presented by Herb Sutter on his CppCon 2016 talk, "Leak-Freedom in C++... By Default.", which presented a GC like implementation for C++, using deferred pointer.

https://www.youtube.com/watch?v=JfmTagWcqoE

On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
> On Monday, 16 October 2017 at 09:58:46 UTC, Ecstatic Coder wrote:
>> On Sunday, 15 October 2017 at 20:42:36 UTC, Laeeth Isharc wrote:
>>> On Sunday, 15 October 2017 at 07:21:55 UTC, Ecstatic Coder wrote:
>>>> [...]
>>>
>>> Out of curiosity, what is it that stops you keeping the heap small and allocating memory manually for the rest?
>>
>> In D I've the added complexity in trying to use the game engine (cocos2dx, unreal, cryengine) C++ libraries from D.
>>
>> So that's not worth the effort, if I can't use D's powerful standard library as usual.
>>
>> I don't like the idea that any hidden object allocation or string concatenation can trigger a GC for an undefined amount of time.
>>
>> In C++ you also have plenty of objects constructors/destructors called everywhere in your back, but none of them will ever trigger a GC...
>
> A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.
>
> Have you tried using a @nogc main loop in your programs/games? I'm curious to learn why that might not have worked for you.
>
> Atila

Very honestly, shortly after your remark I've tried to use D in connection with cocos2d-x for a small mobile sports game, and after two days I've given up.

I've never managed to find an easy way to make D play well with cocos2d-x. Don't ask me about having it run on android.

But I'm not disgusted.

I still remain VERY interested in being able to developing all my desktop/mobile gaming developements in D.

It's just that it seems that I'm not smart enough to make this D/cocos2d-x/android magic happen by myself.

And as I said, I'd prefer to be able to regularly ask D to progressively collect its bits of memory in some limited and predefined amount of time (xxx ms) when and where I've decided to, in the Nim way.

For that also I'm clearly not smart enough to do the job by myself, and Dmitry has already explained me twice why he's against that...

So at the moment I'm just waiting that some D/GC/Android genius manages to make the impossible possible...

On Monday, 16 October 2017 at 14:24:57 UTC, Paulo Pinto wrote:
> On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
>>> A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.
>>
>> I don't use shared_ptr much, but why would a single shared_ptr be that slow?
>
> Cascade deletion of nested data structures, with the possibility of causing stack overflow.

Cascaded deletion? That's far more than a shared_ptr… Nobody does that in real code, unless they are prototyping.

On Monday, 16 October 2017 at 16:11:05 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 16 October 2017 at 14:24:57 UTC, Paulo Pinto wrote:
>> On Monday, 16 October 2017 at 14:14:50 UTC, Ola Fosheim Grøstad wrote:
>>> On Monday, 16 October 2017 at 13:49:50 UTC, Atila Neves wrote:
>>>> A std::shared_ptr going out of scope can pause the program for just as long as a GC mark-and-sweep.
>>>
>>> I don't use shared_ptr much, but why would a single shared_ptr be that slow?
>>
>> Cascade deletion of nested data structures, with the possibility of causing stack overflow.
>
> Cascaded deletion? That's far more than a shared_ptr… Nobody does that in real code, unless they are prototyping.

You would be amazed what real code on Fortune 500's looks like, specially if it comes from offshored projects.