Why aren't you asking about ricing your desktop? This is too advanced for /g/

D is too difficult and uncool for SF hipsters to adopt, so naturally I love it to death.

>>52175910
I don't think it resembles C# and Java pretty much. What gave you the idea?

It basically adopted the you-pay-what-you-use mentallity from C++.
That doesn't reflect in their libraries from time to time.

>>52178576
>I don't think it resembles C# and Java pretty much. What gave you the idea?
The formatting looks very Java like though.

https://en.m.wikibooks.org/wiki/D_(The_Programming_Language)/d2/Lesson_3

I mean, D has the option to use pointers which Java doesn't but it never forces you to.

>>52178216
I'm asking because I never seen D talked about on /g/. Not sure if it is because D is a bad language or because people just don't dabble with it.

>>52175910
D fixed 90+% of C++'s problems, then fucking fumbled the ball at the 1 yard line by including mandatory GC.

Yes, they added the 'nogc' directive a year ago, but it literally has to be added to every single function and sub-function to get what you really want.

I haven't studied D but my first guess is that it doesn't do as well at reducing the power vs. features vs. quality of life tradeoff as some of the more modern languages like Rust and Swift do. If that guess is true, it's going to have a hard time competing. Both Rust and Swift are picking up momentum at an almost shocking pace and Go has had momentum for a while.

>>52182009
Does GC really suck that much? I have a simplistic view but GC sounds like automatic memory management vs manual memory management.

>>52183212
My understanding (pls correct me guys if I'm wrong) is that garbage collectors have to periodically freeze everything to collect garbage, and the collection itself has overhead.

This is a huge problem in applications where these "gaps" aren't affordable, and as such are written in languages that don't use garbage collection.

>>52183212
>>52183238
GC is great for use cases where you can just throw more RAM and servers at a problem and jitter/stalls can't be perceived directly by users. (e.g., web server farms generating HTML or whatever)

It sucks for anything RAM constrained or running locally with a graphic interface, which is largely why Android is such a performance dog compared to iOS.

GC roughly doubles RAM requirements, causes frequent small pauses that are sometimes big enough to stall a frame or twenty, and reduces overall efficiency by constant cache trashing.

The only thing about it is that heap maintenance for deallocation can easily be pushed off to a separate core from the critical path loop, but this can be achieved in non-GC systems fairly easily as well when it's enough of an improvement to bother changing.

It started decently, it became a mess of annotations and weird ass syntax, also forced GC if you want to use anything from the stdlib.

>>52183469
I remember when Xcode was built using (the thankfully now deprecated and thoroughly buried) Objective-C garbage collection. It was so horrible. Thankfully Apple wasn't stupid and killed off Obj-C GC in favor of ARC.

>>52183490
It was always GC regardless of std library usage.
The ability to generally manually disable GC is relatively new, as is the resulting issue that the std lib still forces it most of the time.

Walter Bright was sucking the enterprise cock trying to make the language appealing to currynigger sweatshops, and only started the massive backpedaling when people finally woke up to the fact that GC still has terminally unacceptable drawbacks for a lot of systems programming use cases.

D and Go were always realistically going after Java and C#'s lunch, not C/C++'s.
Rust might have had a shot if they had focused on generating more efficient intermediate code and not gotten sidetracked by concerns about microagressive mansplaining to transfaggots.

>>52183674
>microagressive mansplaining
what does that even mean

>>52183766
it means to check your privilege, shitlord