Interesting performance data-point

Mike Shah mshah.475 at gmail.com
Sun Jan 5 02:00:17 UTC 2025


Nice post -- thanks for sharing this case study!

On Tuesday, 31 December 2024 at 15:36:31 UTC, Don Allen wrote:
> I think this illustrates a strength of D that I don't think 
> enough people understand -- the ability to talk directly and 
> easily to the C world. People complain that D doesn't have a 
> rich set of libraries. It doesn't need one; all the C libraries 
> are almost as easily accessible from D as they are from C or 
> C++. And this has gotten even easier with the advent of 
> ImportC, which I think is a very important addition to D and 
> worth continued development to hide the craziness in C header 
> files.

Agreed, the effectively 100% interop with C is one of DLang's 
awesome superpowers :)

The interop with C++ is also quite good -- I think D and Swift 
are the only languages I've seen otherwise to have interop in a 
nearly perfect or good state with all three of C, C++, 
Objective-C interop.

Some of my favorite other superpowers (that you probably already 
know, but in case anyone new is lurking here):
1. metaprogramming and templates
2. CTFE
3. Slicing
4. Most of the defaults match my preference (default-on bounds 
checking, initialized variables)
5. Module system (i.e. no messing around distinguishing with 
source and header files).
6. Ranges
7. Tooling: Dub, profiler, gc-profiler, cov (Might not be perfect 
tools, but having a package manager and default build system is 
really nice for those just getting started)
8. ...my list could go on -- but I'll just say I have fun doing 
real software engineering in D :)

> [...] Things are just more difficult, mainly because the user 
> plays a bigger role in memory management in Rust than in 
> languages, like D, that provide a GC (I simply do not 
> understand the anti-GC religious fanatics, especially when we 
> are talking about ordinary applications on today's multi-ghz 
> hardware with huge amounts of memory). D's performance is 
> comparable (except in the case of the AMEX utility, where it is 
> a lot better) and the code is more readable. Unfortunately, 
> people jump on band-wagons mindlessly.

I think the funny thing is that D provides several memory 
management strategies, and somehow the anti-GC crowd got stuck on 
the default. Applications like games where control over memory is 
needed (whether that means simply preallocating, explicitly 
calling when to GC, not using GC at all and using malloc, frame 
allocation, using double-stack buffers, etc.) is all possible :)


More information about the Digitalmars-d mailing list