Thread overview
About D and a gratitude
Mar 02, 2019
Matheus
Mar 02, 2019
Ali Çehreli
Mar 05, 2019
Greatsam4sure
Mar 08, 2019
Ecstatic Coder
Mar 09, 2019
H. S. Teoh
Mar 10, 2019
Ecstatic Coder
March 02, 2019
First of all sorry my English, second and if that matters to anyone, I decided to open this thread to show my gratitude toward those who spend their time to help this language.

I've been using D for awhile and I decided to do this, because other day I was looking to understand more about Front-End vs Back-End (In Compilers).

I had a little grasp about this matter, but I wanted a correct answer and a simple search lead me to this: https://wiki.dlang.org/DMD_Source_Guide

While my question was solved I stop for a minute to contemplate this document and all the time/work someone put on it.

Another case is this: https://dlang.org/spec/spec.html - look all the effort.

While I'm talking about documents... there are many tools around too.

Talking about the language right now it attend my needs. I'm C programmer who never got in to C++, I just couldn't stand that language. And a few years ago I was looking around and I found D, which I appreciated from the beginning.

One thing that I liked at first was the fact that It has a built-in GC. While I see some people bashing it. I never had big problems even when writing games.

It's a raining Saturday morning where I live and took this time to show the community some gratitude.

Thanks,

Matheus.
March 02, 2019
Thank you for writing this. It's always the negative experiences that move people to the keyboard.

On 03/02/2019 05:11 AM, Matheus wrote:

> show my gratitude toward those who spend
> their time to help this language.

Same here. I'm aware of the many great people working for me. Thank you! :)

> It has a built-in GC.
> While I see some people bashing it. I never had big problems even when
> writing games.

Same here. The GC has helped me so far.

> It's a raining Saturday morning where I live

Same here. :)

Ali

March 05, 2019
On Saturday, 2 March 2019 at 22:10:52 UTC, Ali Çehreli wrote:
> Thank you for writing this. It's always the negative experiences that move people to the keyboard.
>
> On 03/02/2019 05:11 AM, Matheus wrote:
>
> > show my gratitude toward those who spend
> > their time to help this language.
>
> Same here. I'm aware of the many great people working for me. Thank you! :)
>
> > It has a built-in GC.
> > While I see some people bashing it. I never had big problems
> even when
> > writing games.
>
> Same here. The GC has helped me so far.
>
> > It's a raining Saturday morning where I live
>
> Same here. :)
>
> Ali
Dlang is a joy and a love to work with. Thanks to the team behind it. May your dreams for dlang become a reality and dlang grow to be number one language of choice for all


March 08, 2019
On Saturday, 2 March 2019 at 13:11:17 UTC, Matheus wrote:
> First of all sorry my English, second and if that matters to anyone, I decided to open this thread to show my gratitude toward those who spend their time to help this language.

+1 :)

> One thing that I liked at first was the fact that It has a built-in GC. While I see some people bashing it. I never had big problems even when writing games.

I think that those who bash D's GC are mostly those who would like to use D as an alternative to C and C++, while in those very few cases where C and C++ still remain the most obvious solutions, like OS/embedded/game-engine development, only the lack of a GC can **completely** remove the **risk** of a GC application freeze.

But for those who like me use D only as an alternative to scripting languages like Python, Ruby, Perl, etc, D's GC has never been a problem, but a blessing.

The only improvement I would be glad to see in D's GC is that it works incrementally (like Unity's new C# GC).

https://blogs.unity3d.com/2018/11/26/feature-preview-incremental-garbage-collection/

But very honestly, for my personal file processing scripts, as far as I remember this has never been a problem.

So I'm also happy to have the opportunity to use D for almost all my file scripting needs, as in this domain I can assure you that D is by far one of the best alternative out there :)

March 08, 2019
On Fri, Mar 08, 2019 at 06:21:51PM +0000, Ecstatic Coder via Digitalmars-d wrote:
> On Saturday, 2 March 2019 at 13:11:17 UTC, Matheus wrote:
[...]
> > One thing that I liked at first was the fact that It has a built-in GC.  While I see some people bashing it. I never had big problems even when writing games.
> 
> I think that those who bash D's GC are mostly those who would like to use D as an alternative to C and C++, while in those very few cases where C and C++ still remain the most obvious solutions, like OS/embedded/game-engine development, only the lack of a GC can **completely** remove the **risk** of a GC application freeze.
> 
> But for those who like me use D only as an alternative to scripting languages like Python, Ruby, Perl, etc, D's GC has never been a problem, but a blessing.

I come mostly from the C/C++ camp, and while I do sometimes write short utilities in D that could be done with a Perl (or other scripting language) script, my main focus is C/C++-style applications.  Yet I find the GC to be a big blessing, rather than the curse some people seem to think it is.  It has significantly improved my productivity, eliminated an entire class of bugs, improved my APIs, improved the kind of algorithms I could write (by not making every non-trivial algorithm a monumental exercise in tight-rope balancing between memory management, algorithmic needs, more memory management, resource usage, memory management, and yet more memory management, that's the staple of C/C++ code of equivalent functionality), and given me the ability to focus on and make progress in the problem domain rather than micro-managing memory every other minute of writing code.

Even with the suboptimal GC that D has today, performance has rarely been a major problem.  When it becomes a problem, there are ways of mitigating it that doesn't involve rewriting entire APIs -- the kind of thing you end up doing in C/C++ when you need to change how you manage memory -- because memory management in C/C++ permeates every aspect of your code, and it's almost impossible not to think about memory management every other minute you write code, and it's practically impossible not to have memory management considerations clutter all over your APIs even if the code logically speaking has nothing to do with memory management. It gets into your face, into your hair, and under your skin, and even if you're a hero-cowboy coder who can navigate this complex mess all it takes is ONE slip-up, and you have a memory leak, segfault, or security hole in your hands. So much effort is spent on memory management when writing C/C++ code, yet it all comes crashing down like a tower of cards at the slightest provocation. It's totally incommensurate, esp. if you're trying to make progress in the lousy problem domain rather than babysitting memory management issues all day long.

Give me a GC any day, seriously.

And if you ever need to, malloc/free is just a function call away in D, for those times when you actually *need* to take hold of the reins. (Unlike Java that coddles you so much it won't allow you to reach under the hood for malloc, even when it becomes a necessity.)  There's a time and place for this, but in general, I say gimme the GC so that I don't have to debug memory leakage in a linked-list for the 1000th time in my career, or track down an obscure untraceable dangling pointer bug for the 500th time in my lifetime that's far too short to squander on such needless annoyances.


[...]
> So I'm also happy to have the opportunity to use D for almost all my file scripting needs, as in this domain I can assure you that D is by far one of the best alternative out there :)

For me, D straddles that delicate (and very difficult!) balance between being powerful enough for complex, large-scale applications, performant enough for intensive computations, and simple enough to meet any one-off scripting needs that might arise.  Most languages can only handle one of the above; a few can handle two.  But I've yet to find one that can master all three like D does.  These days I'm finding less and less need for scripting languages and what-not.  D trumps them all, and comes with the bonus that should that "one-off script" evolve into something more than just a script, the code just fits itself into a more structured, larger-scale design naturally.  I never have to worry about "rewriting that hackish Perl script into a better-designed C++ program"; I just write the script in D and then it becomes a full-fledged program as time goes.  Marvelous.


T

-- 
Computers aren't intelligent; they only think they are.
March 10, 2019
> For me, D straddles that delicate (and very difficult!) balance between being powerful enough for complex, large-scale applications, performant enough for intensive computations, and simple enough to meet any one-off scripting needs that might arise.  Most languages can only handle one of the above; a few can handle two.  But I've yet to find one that can master all three like D does.  These days I'm finding less and less need for scripting languages and what-not.  D trumps them all, and comes with the bonus that should that "one-off script" evolve into something more than just a script, the code just fits itself into a more structured, larger-scale design naturally.  I never have to worry about "rewriting that hackish Perl script into a better-designed C++ program"; I just write the script in D and then it becomes a full-fledged program as time goes.  Marvelous.

Apart from Crystal, I can't think of any other strongly-typed language that I've ever used which can provide this level of type safety and execution performance, while still preserving the expressiveness and productivity of a scripting language.

And I'm really fond of the simple and unified way in which strings, arrays and maps are managed in D (null initialization, ~= appending operator, slices, etc). Brilliant !!!