D Programming Language

https://dlang.org/

by arcadia_leak • 5 months ago

216 235 5 months ago

dlang.org

KnuthIsGod• 5 months ago

Sigh.

Ownership and borrowing are so much less baroque in D than in Rust. And compile times are superb.

In a better world, we would all be using D instead of C, C++ or Rust.

However in this age of Kali...

pjmlp27• 5 months ago

Slowly it is going to be only skills.md.

I agree with the sentiment, I really like D and find a missing opportunity that it wasn't taken off regarding adoption.

Most of what made D special in D is nowadays partially available in mainstream languages, making the adoption speech even harder, and lack of LLM training data doesn't help either.

bigstrat2003• 5 months ago

lack of LLM training data doesn't help either.

That shouldn't stop any self-respecting programmer.

baruch2• 5 months ago

I work with D and LLMs do very well with it. I don't know if it could be better but it does D well enough. The problem is only working on a complex system that cannot all be held in context at once.

gmueckl• 5 months ago

My experience is that all LLMs that I have tested so far did a very good job producing D code.

I actually think that the average D code produced has been superior to the code produced for the C++ problems I tested. This may be an outlier (the problems are quite different), but the quality issues I saw on the C++ side came partially from the ease in which the language enables incompatible use of different features to achieve similar goals (e.g. smart_ptr s new/delete).

chhs• 5 months ago

For those curious what ownership and borrowing looks like in D: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

randfur• 5 months ago

I don't know D so I'm probably missing some basic syntax. If pointers cannot be copied how do you have multiple objects referencing the same shared object?

uecker2• 5 months ago

Is there any experience on how this works in practice?

fooker3• 5 months ago

This is a somewhat simplistic view of ownership and borrowing for modern programming languages.

Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names.

An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers.

This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)

torginus4• 5 months ago

OOP and ownership are two concepts that mix poorly - ownership in the presence of OOP-like constructs is never simple.

The reason for that is OOP tends to favor constructs where each objects holds references to other objects, creating whole graphs, its not uncommon that from a single object, hundreds of others can be traversed.

Even something so simple as calling a member function from a member function becomes incredibly difficult to handle.

Tbh - this is with good reason, one of the biggest flaws of OOP is that if x.foo() calls x.bar() in the middle, x.bar() can clobber a lot of local state, and result in code that's very difficult to reason about, both for the compiler and the programmer.

And it's a simple case, OOP offers tons of tools to make the programmers job even more difficult - virtual methods, object chains with callbacks, etc. It's just not a clean programming style.

Edit: Just to make it clear, I am not pointing out these problems, to sell you or even imply that I have the solution. I'm not saying programming style X is better.

FeepingCreature• 5 months ago

I work at a D company. We tend to use OOP only for state owners with strict dependencies, so it's rare to even get cycles. It is extremely useful for modeling application state. However, all the domain data is described by immutable values and objects are accessed via parameters as much as fields.

When commandline apps were everywhere, people dreamed of graphical interfaces. Burdened by having to also do jobs that it was bad at, the commandline got a bad reputation. It took the dominance of the desktop for commandline apps to find their niche.

In a similar way, OOP is cursed by its popularity. It has to become part of a mixed diet so that people can put it where it has advantages, and it does have advantages.

arcadia_leak22• 5 months ago

On the flipside, with OOP is usually quite easy to put a debugger breakpoint on a particular line and see the full picture of what the program is doing.

In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.

pjmlp27• 5 months ago

It worked alright for Rust, and yes Rust does support OOP, there are many meanings to what is OOP from CS point of view.

I have ported Ray Tracing in One Weekend into Rust, while keeping the same OOP design from the tutorial, and affine types were not an impediment to interfaces, polymorphism and dynamic dispatch.

abbbyz• 5 months ago

one of the biggest flaws of OOP is that if x.foo() calls x.bar() in the middle, x.bar() can clobber a lot of local state, and result in code that's very difficult to reason about

That's more a problem of having mutable references, you'd have the same problem in a procedural language.

fuzztester4• 5 months ago

Kali Yuga.

https://en.wikipedia.org/wiki/Kali_Yuga

4gotunameagain2• 5 months ago

D is like a forced meme at that point.

Never has an old language gained traction, its all about the initial network effects created by excitement.

No matter how much better it is from C now, C is slowly losing traction and its potential replacements already have up and running communities (Rust, zig etc)

kitd3• 5 months ago

Python was first released in 1991. It rumbled along for about 20 years until exploding in popularity with ML and the rise of data science.

querez• 5 months ago

That's not how I remember it. Excitement for python strongly predated ML and data science. I remember python being the cool new language in 1997 when I was still in high school. Python 2.4 was already out, and O'Reilly had put several books kn the topic already it. Python was known as this almost pseudo code like language thst used indentation for blocking. MIT was considering switching to it for its introductory classes. It was definitely already hyped back then -- which led to U Toronto picking it for its first ML projects that eventually everyone adopted when deep learning got started.

nickm12• 5 months ago

Python crossed the chasm in the early 2000s with scripting, web applications, and teaching. Yes, it's riding an ML rocket, but it didn't become popular because it was used for ML, it was chosen for ML because it was popular.

eddythompson802• 5 months ago

Python was common place long before ML. Ever since 1991, it would jump in popularity every now and then, collect enough mindshare, then dives again once people find better tools for the job. It long took the place of perl as the quick "linux script that's too complex for bash" especially when python2 was shipping with almost all distros.

For example, python got a similar boost in popularity in the late 2000s and early 2010s when almost every startup was either ruby on rails or django. Then again in the mid 2010s when "data science" got popular with pandas. Then again in the end of 2010s with ML. Then again in the 2020s with LLMs. Every time people eventually drop it for something else. It's arguably in a much better place with types, asyncio, and much better ecosystem in general these days than it was back then. As someone who worked on developer tools and devops for most of the time, I always dread dealing with python developers though tbh.

nottorp• 5 months ago

Oh? How about Raymond's "Why python?" article that basically described the language as the best thing since sliced bread? Published in 2000, and my first contact with python.

pjmlp27• 5 months ago

Not really, back in 2003 when I joined CERN it was already the offical scripting language on ATLAS, our build pipeline at the time (CMT) used Python, there were Python trainings available for the staff, and it was a required skill for anyone working in Grid Computing.

I started using Python in version 1.6, there were already several O'Reilly books, and Dr.Dobbs issues dedicated to Python.

flohofwoe• 5 months ago

Python had already exploded in popularity in the early 2000s, and for all sorts of things (like cross-platform shell scripting or as scripting/plugin system for native applications).

arcadia_leak22• 5 months ago

This is not true. It took about 20 years for Python to reach the levels of its today's popularity. JavaScript also wasn't so dominant and omnipresent until the Chrome era.

Also, many languages that see a lot of hype initially lose most of their admirers in the long run, e.g. Scala.

gspr4• 5 months ago

Never has an old language gained traction, its all about the initial network effects created by excitement.

Python?! Created in 1991, became increasingly popular – especially in university circles – only in the mid-2000s, and then completely exploded thanks to the ML/DL boom of the 2010s. That boom fed back into programming training, and it's now a very popular first language too.

Love it or hate it, Python was a teenager by the time it properly took off.

einr2• 5 months ago

Not everything needs to have "traction", "excitement" or the biggest community. D is a useful, well designed programming language that many thousands of people in this vast world enjoy using, and if you enjoy it too, you can use it. Isn't that nice?

4gotunameagain2• 5 months ago

Oh a programming language certainly needs to have traction and community for it to succeed, or be a viable option for serious projects.

You can code your quines in whatever you'd like, but a serious project needs existence of good tooling, good libraries, proven track record & devs that speak the language.

bingemaker• 5 months ago

Off topic: Back in the day, C++ programming books Andrei Alexandrescu are a joy to read, especially, Modern C++ design.

Also, this presentation https://accu.org/conf-docs/PDFs_2007/Alexandrescu-Choose_You... killed a lot of bike shedding!

kombine• 5 months ago

I was personally a lot more excited by D and subsequently Nim, but ultimately it's Rust and Zig that got adoption. Sigh.

jakkos• 5 months ago

I often see people lament the lack of popularity for D in comparison to Rust. I've always been curios about D as I like a lot of what Rust does, but never found the time to deep dive and would appreciate someone whetting my appetite.

Are there technical reasons that Rust took off and D didn't?

What are some advantages of D over Rust (and vice versa)?

pjmlp27• 5 months ago

More like the companies that jumped into D versus Rust, D only had Facebook and Remedy Games toy a bit with it.

Many of us believe on automatic memory management for systems programming, having used quite a few in such scenarios, so that is already one thing that D does better than Rust.

There is the GC phobia, mostly by folks that don't get not all GCs were born alike, and just like you need to pick and chose your malloc()/free() implementation depending on the scenario, there are many ways to implement a GC, and having a GC doesn't preclude having value types, stack and global memory segment allocation.

D has compile time reflection, and compile time metaprogramming is much easier to use than Rust macros, and it does compile time execution as well.

And the compile times! It is like using Turbo Pascal, Delphi,... even thought the language is like C++ in capabilities. Yet another proof complexity doesn't imply slow compile natives in a native systems language.

For me, C# and Swift replace the tasks at work were I in the past could have reached for D instead, mostly due to who is behind those languages, and I don't want to be that guy that leaves and is the one that knew the stack.

deng3• 5 months ago

Many of us believe on automatic memory management for systems programming

The problem is the term "systems programming". For some, it's kernels and device drivers. For some, it's embedded real-time systems. For some, it's databases, game engines, compilers, language run-times, whatever.

There is no GC that could possibly handle all these use-cases.

arcadia_leak22• 5 months ago

D and Rust are on the opposite sides at dealing with memory safety. Rust ensures safety by constantly making you think about memory with its highly sophisticated compile-time checks. D, on the other hand, offers you to either employ a GC and forget about (almost) all memory-safety concerns or a block scoped opt-out with cowboy-style manual memory management.

D retains object-oriented programming but also allows functional programming, while Rust seems to be specifically designed for functional programming and does not allow OOP in the conventional sense.

I've been working with D for a couple of months now and I noticed that it's almost a no-brainer to port C/C++ code to D because it mostly builds on the same semantics. With Rust, porting a piece of code may often require rethinking the whole thing from scratch.

nurettin• 5 months ago

block scoped opt-out with cowboy-style manual memory management

Is this a Walter Bright alt? I've seen him use the cowboy programmer term a few times on the forum before.

ender341341• 5 months ago

I think 3 things

1. D had a split similar to python 2 vs 3 early on with having the garbage collector or not (and therefor effectively 2 standard libraries), but unlike python it didn't already have a massive community that was willing to suffer through it.

2. It didn't really have any big backing. Rust having Mozilla backing it for integration with Firefox makes a pretty big difference.

3. D wasn't different enough, it felt much more "this is c++ done better" than it's own language, but unlike c++ where it's mostly a superset of c you couldn't do "c with classes" style migrations

otabdeveloper4• 5 months ago

Are there technical reasons that Rust took off and D didn't?

Yes. D tried to jump on the "systems programming with garbage collection" dead horse, with predictable results.

(People who want that sort of stupidity already have Go and Java, they don't need D.)

tmtvl5• 5 months ago

Go wasn't around when D was released and Java has for the longest time been quite horrible (I first learnt it before diamond inference was a thing, but leaving that aside it's been overly verbose and awkward until relatively recently).

lelanthran• 5 months ago

(People who want that sort of stupidity already have Go and Java, they don't need D.)

Go wasn't around when D was created, and Java was an unbelievable memory hog, with execution speeds that could only be described as "glacial".

As an example, using my 2001 desktop, the `ls` program at the time was a few kb, needed about the same in runtime RAM and started up and completed execution in under 100ms.

The almost equivalent Java program I wrote in 2001 to list files (with `ls` options) took over 5s just to start up and chewed through about 16MB of RAM (around 1/4 of my system's RAM).

Java was a non-starter at the time D came out - the difference in execution speed between C++ systems programs and Java systems programs felt, to me (i.e. my perception), larger than the current difference in performance between C++/C/Rust programs and Bash shell scripts.

badsectoracula• 5 months ago

One feature of D that i really wish other languages would adopt (not sure about Rust but i also think it lacks it, though if it has it to a similar extent as D it might be the reason i check it again more seriously) is the metaprogramming and compile-time code evaluation features it has (IIRC you can use most of the language during compile time as it runs in a bytecode VM), down to even having functions that generate source code which is then treated as part of the compilation process.

Of course you can make codegen as part of your build process with any language, but that can be kludgy (and often limited to a single project).

skocznymroczny2• 5 months ago

Arguably, most of the metaprogramming in D is done with templates and it comes with all the flaws of templates in C++. The error messages are long and it's hard to decipher what exactly went wrong (static asserts help a lot for this, when they actually exist). IDE support is non-existent after a certain point because IDE can't reason about code that doesn't exist yet. And code gets less self-documenting because it's all Output(T,U) foo(T, U)(T t, U u) and even the official samples use auto everywhere because it's hard to get the actual output types.

ameliaquining• 5 months ago

Rust has procedural macros, which turn out to be a good-enough substitute for real compile-time reflection for surprisingly many use cases, though nowhere near all of them. (In particular, Serde, the universally-adopted framework/library for serializing and deserializing arbitrary data types, is a third-party library powered by procedural macros.)

Real compile-time reflection is in the works; the very earliest stages of a prototype implementation were released to the nightly channel last month (https://github.com/rust-lang/rust/pull/146923), and the project has proposed (and is likely to adopt) the goal of completing that prototype implementation this year (https://rust-lang.github.io/rust-project-goals/2026/reflecti...), though it most likely will not reach the stable channel until later than that, since there are a whole lot of complicated design questions that have to be considered very carefully.

vaylian• 5 months ago

Are there technical reasons that Rust took off and D didn't?

My (somewhat outdated) experience is that D feels like a better and more elegant C++. Rust certainly has been influenced by C and C++, but it also took a lot of inspiration from the ML-family of languages and it has a much stronger type system as a consequence.

deng3• 5 months ago

Are there technical reasons that Rust took off and D didn't?

As someone who considered it back then when it actually stood a chance to become the next big thing, from what I remember, the whole ecosystem was just too confusing and simply didn't look stable and reliable enough to build upon long-term. A few examples:

* The compiler situation: The official compiler was not yet FOSS and other compilers were not available or at least not usable. Switch to FOSS happened way too late and GCC support took too long to mature.

* This whole D version 1 vs version 2 thingy

* This whole Phobos vs Tango standard library thingy

* This whole GC vs no-GC thingy

This is not a judgement on D itself or its governance. I always thought it's a very nice language and the project simply lacked man-power and commercial backing to overcome the magical barrier of wide adoption. There was some excitement when Facebook picked it up, but unfortunately, it seems it didn't really stick.

amelius3• 5 months ago

How many people were working on the core compiler/language at the time versus Rust? This could explain it.

anal_reactor• 5 months ago

Can you elaborate on the points? I know nothing about D, but I'm just curious about old drama

Kapendev• 5 months ago

This whole GC vs no-GC thingy

And I am here, enjoying both. Life is good.

kjs32• 5 months ago

The compiler situation

I think people forget this. I know a lot of folks that looked at D back when it needed to win mindshare to compete with the currently en vogue alternatives, and every one of them nope'd out on the licensing. By the time they FOSS'ed it, they'd all made decisions for the alternative, and here we are.

dadoum• 5 months ago

D has much better metaprogramming compared to Rust. That has been one of the only things making me still write a few D programs. You can do compile time type introspection to generate types or functions from other elements without having to create a compiler plug-in parsing Rust and manipulating syntax trees.

Rust has some of the functional programming niceties like algebraic data types and that's something lacking in D.

p0nce3• 5 months ago

Are there technical reasons that Rust took off and D didn't?

This talk explain why, it's not technical: https://www.youtube.com/watch?v=XZ3w_jec1v8

What are some advantages of D over Rust (and vice versa)?

Advantages for D: Build faster, in typical programs you would need about 20 packages not 100, COM objects, easy meta-programming, 3 compilers. GC, way better at scripting.

Advantages for Rust: borrow-checker is better. rustup.

arcadia_leak22• 5 months ago

This talk explain why, it's not technical: https://www.youtube.com/watch?v=XZ3w_jec1v8

Really good talk, I remember watching it when it came out. Elm is what got me looking into FP several years ago, a nice language it was.

self_awareness• 5 months ago

I never understood why this language didn't gain much traction. It seems very solid.

At the same time, I've never used it, I'm not sure why.

Anyway, the author of D language is here on HN (Walter Bright).

erzhan89• 5 months ago

When I was student, our group was forced to use D lang instead C++ for CS2* classes. That was back in 2009. After 16 years I see that level of adoption did not change at all.

dhruv3006• 5 months ago

I remember the creator of D programming Language replying to me on HN on one of my posts!

https://news.ycombinator.com/item?id=46261452

FrozenSynapse• 5 months ago

I had an interview at Facebook 10+ years ago and my interviewer was the other creator!

jibal8• 5 months ago

Walter's a regular on HN.

This very post is probably his too, under an alt :)

The probability of that is virtually zero. Walter is a principled person, has better things to do, and his writing style is vastly different from the OP's.

abcd_f• 5 months ago

This very post is probably his too, under an alt :)

WhereIsTheTruth• 5 months ago

D is a treasure we should continue to cherish and protect

A language with sane Compile Time features (Type Introspection, CTFE, mixins, etc)

A language that can embrace C ecosystem with sane diagnostics

A language that ships with its own optimizing code generator and inline assembler!

A compiler that compiles code VERY fast

A compiler with a readable source code that bootstraps itself in just 5 seconds

People who dunk on it "bEcAuSe iT Is nOt MaInsTrEaM" are clueless

Rounin• 5 months ago

As far as adoption is concerned, I'm not sure it should be that big of a concern.

After all, D is supported by GCC and Clang and continually being maintained, and if updates stopped coming at some point in the future, anyone who knew a bit of C / Java / insert language here could easily port it to their language of choice.

Meanwhile, its syntax is more expressive than many other compiled languages, the library is feature-rich and fairly tidy, and for me it's been a joy to use.

pjmlp27• 5 months ago

GCC usually drops frontends if there are no maintainers around, it already happened to gcj, and I am waiting for the same to happen to gccgo any time now, as it has hardly gotten any updates since Go 1.18.

The team is quite small and mostly volunteers, so there is the question how long can Walter Bright keep at it, and who will keep it going afterwards when he passes the torch.

schveiguy4• 5 months ago

gdc is 100% Iain Buclaw. But he and Walter collaborate on needs for gcc compatibility, as long as Iain is around, gdc will be around.

It is true we have a small team. But we are a dedicated team.

nicwilson• 5 months ago

It has an LLVM backend, LDC, that is separate from the LLVM project/Clang.

skocznymroczny2• 5 months ago

I like D in general, however it is missing out in WASM where other languages like Rust, Zig, even Go are thriving. Official reasoning usually included waiting for GC support from WASM runtime, but other GC languages seem to just ship their own GC and move on.

destructionator• 5 months ago

OpenD added almost-full (you can't catch exceptions or spawn threads, so not really full, but the GC and such work fine) wasm support with like .... i think it was less than one day of work. wasm sucks though, what a miserable platform.

Defletter• 5 months ago

Why is WASM a miserable platform?

fuzztester4• 5 months ago

what's the latest news about OpenD, anyone?

I had read about the split (D vs. OpenD) recently on the Dlang newsgroup.

Also, just had the thought that the split may damage Dlang's progress / prospects, for users, like the Phobos issue etc. stuff was supposed to have done.

I don't know much about those details either, I had just read a bit about it earlier, as an interested light user of the language.

9999000009993• 5 months ago

What can D do other languages can't?

Say your starting a new Staff Engineer or Tech Lead job. What gets you to convince a CTO that we need to have a team learn D ?

On the flip side, where are the 200k base salary D positions.

Get me an interview in 2 months and I'll drop 10 hours a week into learning

arcadia_leak22• 5 months ago

Well, I would say it's more like glasses - you can't convince those who don't wear them, and you don't need to convince those who need them either.

9999000009993• 5 months ago

What problem is D solving ?

rafaelmn7• 5 months ago

IMHO D just missed the mark with the GC in core. It was released in a time where a replacement for C++ was sorely needed, and it tried to position itself as that (obvious from the name).

But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further.

Meanwhile in the C/C++ replacement camp there was nothing credible until Rust showed up, and nowadays I think Zig is what D wanted to be with more momentum behind it.

Still kind of salty about the directions they took because we could have had a viable C++ alternative way earlier - I remember getting excited about the language a lifetime ago :D

fuhsnn• 5 months ago

FIl-C, the new memory-safe C/C++ compiler actually achieved that through introducing a GC, with that in mind I'd say D was kind of a misunderstood prodigy in retrospect.

rafaelmn7• 5 months ago

There's two classes of programs - stuff written in C for historic reasons that could have been written in higher level language but rewrite is too expensive - fill c. Stuff where you need low level - Rust/C++/Zig

arcadia_leak22• 5 months ago

I'd rather say that the GC is the superpower of the language. It allows you to quickly prototype without focusing too much on performance, but it also allows you to come back to the exact same piece of code and rewrite it using malloc at any time. C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless.

Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.

rafaelmn7• 5 months ago

C# or Java don't have this, nor can they compile C code and seamlessly interoperate with it — but in D, this is effortless.

C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point.

Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.

Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision to fit into the use-cases they should have targeted from the start in my opinion.

Look D was an OK language but it had no corporate backing and there was no case where it was "the only good solution". If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better adoption.

optionalsquid2• 5 months ago

My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the languages that commit to a paradigm.

Do you want GC? Great! Do not want GC? Well, you can turn it off, and lose access to most things. Do you want a borrow-checker? Great, D does that as well, though less wholeheartedly than Rust. Do you want a safer C/memory safety? There's the SafeD mode. And probably more that I forget.

I wonder if all these different (often incompatible) ways of using D ends up fragmenting the D ecosystem, and in turn make it that much harder for it to gain critical mass

DeathArrow2• 5 months ago

My (likely unfair) impression of D is that it feels a bit rudderless: It is trying to be too many things to too many people, and as a consequence it doesn't really stand out compared to the languages that commit to a paradigm.

Nim kind of does that, too.

cardanome3• 5 months ago

My (likely unfair) impression of D is that it feels a bit rudderless

The more positive phrasing would be that it is a very pragmatic language. And I really like this.

Currently opinionated langues are really in vogue. Yes they are easier to market but I have personally very soured on this approach now that I am a bit older.

There is not one right way to program. It is fun to use on opinionated language until you hit a problem that it doesn't cover very well and suddenly you are in a world of pain. I like languages that give me escape hatches. That allow me to program they way I want to.

atilaneves• 5 months ago

and lose access to most things

What "most things" are these?

gorgonical• 5 months ago

Re: the point about Zig: Especially considering I used and played a lot with D's BetterC model when I was a student, I wonder as a language designer what Walter thinks about the development and rise in popularity of Zig. Of course, thinking "strategically" about a language's adoption comes off as Machiavellian in a crowd of tinkers/engineers, but I can't help but wonder.

Dwedit• 5 months ago

Zig got too much in to avoiding "hidden behavior" that destructors and operator overloading were banned. Operator overloading is indeed a mess, but destructors are too useful. The only compromise for destructors was adding the "defer" feature. (Was there ever a corresponding "error if you don't defer" feature?)

jibal8• 5 months ago

No, defer is always optional, which makes it highly error prone.

There's errdefer, which only defers if there was an error, but presumably you meant what you wrote, and not that.

BTW, D was the first language to have defer, invented by Andrei Alexandrescu who urged Walter Bright to add it to D 2.0 ... in D it's spelled scope(exit) = defer, scope(failure) = errdefer, and scope(success) which is only run if no error.

pron4• 5 months ago

GC/runtime

1. Runtime: A runtime is any code that is not a direct result of compiling the program's code (i.e. it is used across different programs) that is linked, either statically or dynamically, into the executable. I remember that when I learnt C in the eighties, the book said that C isn't just a language but a rich runtime. Rust also has a rich runtime. It's true that you can write Rust in a mode without a runtime, but then you can barely even use strings, and most Rust programs use the runtime. What's different about Java (in the way it's most commonly used) isn't that it has a runtime, but that it relies on a JIT compiler included in the runtime. A JIT has pros and cons, but they're not a general feature of "a runtime".

2. GC: A garbage collector is any mechanism that automatically reuses a heap object's memory after it becomes unreachable. The two classic GC designs, reference counting and tracing, date back to the sixties, and have evolved in different ways. E.g. in the eighties and nineties there were GC designs where the compiler could either infer a non-escaping object's lifetime and statically insert a `free` or have the language track lifetimes ("regions", 1994) and have the compiler statically insert a `free` based on information annotated in the language. On the other hand, in the eighties Andrew Appel famously showed that moving tracing collectors "can be faster than stack allocation". So different GCs employ different combination of static inference and dynamic information on object reachability to optimise for different things, such as footprint or throughput. There are tradeoffs between having a GC or not, and they also exist between Rust (GC) and Zig (no GC), e.g. around arenas, but most tradeoffs are among the different GC algorithms. Java, Go, and Rust use very different GCs with different tradeoffs.

So the problem with using the terms "runtime" and "GC" colloquially as they're used today is not so much that it differs from the literature, but that it misses what the actual tradeoffs are. We can talk about the pros and cons of linking a runtime statically or dynamically, we can talk about the pros and cons of AOT vs. JIT compilation, and we can talk about the pros and cost of a refcounting/"static" GC algorithm vs a moving tracing algorithm, but talking in general about having a GC/runtime or not, even if these things mean something specific in the colloquial usage, is not very useful because it doesn't express the most relevant properties.

ceteia2• 5 months ago

Does Rust really require reference counting? I thought Rust programs only used reference counting when types like Rc and Arc are used.

Swift seems to require reference counting significantly more than Rust.

gavinray2• 5 months ago

The "GC is slow"/"JIT/VM's are slow" is such a tired, dated take at this point.

Look at C#'s competitive placings with C++/Rust on The Computer Benchmark game due to .NET's ruthless optimization.

rafaelmn7• 5 months ago

It's pretty obvious from the context that runtime/GC means having a runtime with a tracing GC - and the tradeoffs are well known. These discussions were played out over the last two decades - we all know GC can be fast, but there were and are plenty of use-cases where the tradeoffs are so bad that it's a non-starter.

Not to mention that writing a high quality GC is a monumental task - it took those decades for C# and Java to get decent - very few projects have the kind of backing to pull that off successfully.

In practical terms think about the complexity of enabling WASM that someone mentioned in this thread when you reuse C runtime and skip tracing GC.

I'm kind of venting in the thread to be fair, Walter Bright owes me nothing and it's his project, I had fun playing with it. I'm just sad we couldn't have gotten to Zig 20 years ago when we were that close :)

ibgeek• 5 months ago

I used to think of D as the same category as C# and Java, but I realized that it has two important differences. (I am much more experienced with Java/JVM than C#/.Net, so this may not all apply.)

1. Very load overhead calling of native libraries. Wrapping native libraries from Java using JNI requires quite a bit of complex code, configuring the build system, and the overhead of the calls. So, most projects only use libraries written in a JVM-language -- the integration is not nearly as widespread as seen in the Python world. The Foreign Function and Memory (FFM) API is supposed to make this a lot easier and faster. We'll see if projects start to integrate native libraries more frequently. My understanding is that foreign function calls in Go are also expensive.

2. Doesn't require a VM. Java and C# require a VM. D (like Go) generate native binaries.

As such, D is a really great choice when you need to write glue code around native libraries. D makes it easy, the calls are low overhead, and there isn't much need for data marshaling and un-marshaling because the data type representations are consistent. D has lower cognitive overhead, more guardrails (which are useful when quickly prototyping code), and a faster / more convenient compile-debug loop, especially wrt to C++ templates versus D generics.

pjmlp27• 5 months ago

1. Java nowadays has Panama

2. Java and C# can also generate native binaries, just like Go, no need for VM.

3. C++ nowadays has concepts, modules and compile time execution

This wasn't true in 2010, but D has let them catch up with missing features.

tracker1• 5 months ago

Native calls from C# are MUCH better than then the Java experience. It's a massive part of why I chose it when it came out. Today, C# is pretty great... not ever MS dev shop, which is often, like Java, excessively complex for its' own sake.

On #2, I generally reach for either TS/JS with Deno if I need a bit more than a shell script, or Rust for more demanding things. I like C# okay for the work stuff that I do currently though.

ksec• 5 months ago

I continue to think a subset of D without GC, commonly known as "D as C" or Das C could have been marketed as a language of its own with specific target audience in direct competition with Zig.

But I think Walter quite like what D is today.

amelius3• 5 months ago

How good are the big LLMs at writing D code? Just curious.

p0nce3• 5 months ago

With Claude Opus I had no issues.

cocodill• 5 months ago

D is boring, let's see how to recreate the B language:

https://www.youtube.com/playlist?list=PLpM-Dvs8t0VZn81xEz6Ng...

small_model• 5 months ago

Seen D being posted regularly on here, seems like flogging a dead horse. It's the equivalent of keeping grandma on life support when there is no hope.

arcadia_leak22• 5 months ago

You'd be surprised to see how active the D community is, despite your fair point that it's noticeably smaller than in the "competing" (in quotes because it's not a competition, actually) languages.

The latest release [1] was on Jan 7th, and it contains more updates than, say, the latest release of Dart, which has one of the largest corporations behind it.

1. https://dlang.org/changelog/2.112.0.html

schveiguy4• 5 months ago

To be fair, the release cadence has been in a bit of a mess lately. But I expect that to be fixed soon. We don't want 6 months between releases.

lossolo2• 5 months ago

Years ago I got interested in D. It's a great language, but at the time its garbage collector was leaky. There weren't any D entries on the Benchmarks Game back then, so I ported most of the programs to D and optimized them as best I could as a newcomer. Performance wise, D was in the C/Rust/C++ range and in many cases it even beat Rust and C++. I tried to get the community involved to help the language gain wider adoption, but nothing really happened. I think everything has its moment, and D's moment has passed. They didn't make the most of the window when D could have gone mainstream.

igouy2• 5 months ago

weren't any D entries

fwiw nbody.dlang 2005

https://salsa.debian.org/benchmarksgame-team/archive-alioth-...

Like 20 years ago:

https://web.archive.org/web/20060525101747/http://shootout.a...

lossolo2• 5 months ago

Why it was removed a few years ago?

DeathArrow2• 5 months ago

Every talk about D here seems to transform into "why D failed?".

cb3212• 5 months ago

I don't use D.. I find Nim helps with even lower ceremony. That said, it's hard for me to understand how "getting into gcc" is failure. The list of such PLangs is very short. People can be very parochial, though. They probably mean pretty shallow things (just one example, but something like "failed to convert me, personally", or "jobs I'd like to apply for", or etc.).

Maybe people should instead talk about how they use D or what they'd like to see added to D? In an attempt to be the change one wants to see, I'd say named arguments are a real win and there seem to be some stalled proposals for that in D last I checked.

jibal8• 5 months ago

D has named regular arguments and optional regular arguments. It has optional template arguments but not named template arguments.

pjmlp27• 5 months ago

Maybe because there were some expectations when "The D Programming Language" was published back in 2010, regarding where D would be 16 years later.

casey2• 5 months ago

When design a language for everything nobody will use it for anything. When you design a language to simply accomplish one thing people will use it for everything. This is because people get the most efficient training using that simple language for one thing. From there it is only marginally more effort to carry some boilerplate.

That "one thing" could be real or propaganda. Rust's one thing is writing "memory-safe" without GC. Eventually the marginal cost becomes too high or your are tricked by advertising and "graduate" from awk to perl. From there depending on the pull of the community or the actual utility of the language you will use it for more and more tasks. If the community pull is strong your programs start to look like line noise or boilerplate hell. If the utility for your problems is genuine they remain simple but you probably aren't producing the most efficient binaries.

As for why c programmers don't just use -betterc well some do, but for most people the reality is that can just do it in c and prefer c -> c++ (ofc the vast majority of projects just start as c++ which makes -betterC )

c++'s one thing c with objects.

If you learned to code writing Go what did you do?

If you learned to code writing D what did you do?

That's not to say you can't learn to code from writing D just that it discipline, most people don't even know a problem exists before they are already learning some language or tool, nor do they have the goal of building everything, most programmers are lazy they want to build the minimal amount and end up building everything by accident.

Why don't experienced devs use D then? They think if they strive for ideological purity that they won't "build everything" next time, or they just enjoy ideological purity as it's own mental exercises. Unix faithfuls want to show that computing can be (conceptually) simple in implementation and use. Rust programmers want to show that those simple (to use) unix programs can be (memory) safe. To a senior engineer D is just too good and easy to take.

ivolimmen• 5 months ago

I tried some D some time ago, it is a nice language. Given today's landscape of programming languages I think it's difficult to reason why a program should be written in D if there are more programming languages that overlap in features. Also depends on how fast you need to scale in developers, how quickly people can learn a language (and not just the syntax) so popularity is also important. I work in consultancy and this is what I always factor in for a client.

fl0ki• 5 months ago

There are two kinds of post on HackerNews: (1) Trolling Walter, (2) Other

fithisux• 5 months ago

My only problem with D is that gdc does not work on Windows.

I would be happy if they released it without phobos.

Other than that it is excellent.

DMD does its job.

D Programming Language

Related Stories