I have been hearing about dlang for quite some time. But I didnt gave it much of a chance until now.
After watching a video about dlang in which it was showing some of it metacapabilities, cbindings, some things about its standard library I became greatly interested.
What I have written in it
The only thing that I made in it so far has been cryptod which is a library that I wrote to use it for some future networking projects. I needed to be able to use post quantum cryptography which was not available in its standard library neither I was able to find any available package which I could use for that purpose.
Dlang its quite small, there is 2.8k packages(today 10/07/2026) but you might not be able to find as much variety as it comes with rust or golang. That can be a problem for a few people and in itself its why a lot of people decide to not use dlang.
But I wanted this to be different, dlang is filled with a lot of c programmers which are just going to use it for its bindings but I would like for more junior or naive developers to be able to do use that without much pain.
So thats why I wrote cryptod.
How my experience went
Dlang has a lot of features which can be quite enticing but I will not talk about them because I didnt used them a lot.
Raw experience(language itself)
Something that I liked a lot about it its that you dont really have a problem when working with multiple modules, those modules can depend on each other without much problems. Thats great when you are trying to make the project more simple.
Its syntax was quite good it didnt felt weird or had some hyper complicated things compared with c++ or rust. It was clean, simple, and readable. Similar to Java but less verbose.
project structure
It doesnt works the same as golang in which you define a package inside of a folder and then you dont need to import each individual module inside of that folder, dlang was different but it didnt came with any kind of problem.
Here there is an example of what I mean.
# first we need to start a simple project with dub
dub init example
// source/a.d
module a;
import b;
import std.stdio;
void functionA(string message){
writeln("functionA: ", message);
functionB2();
}
// source/b.d
module b;
import a;
import std.stdio;
void functionB(){
functionA("Getting called from functionB");
}
void functionB2(){
writeln("functionB2 called");
}
//source/app.d
import b;
void main(){
functionB();
}
--
Running it with
dub run
you get this output
Starting Performing "debug" build using /usr/bin/dmd for x86_64.
Building example-d ~master: building configuration [application]
Linking example-d
Running example-d
functionA: Getting called from functionB
functionB2 called
Classes and structs
Structs dont work the same as c++ in which its also a class that can inherit, the same goes for classes, in dlang the classes are stored in the heap, and that can be a big problem for some people.
// structs example
struct Person{
uint age=0;
this(uint newAge){
this.age=newAge;
}
}
Person p;// this is valid
Person p=Person(12); // this is also valid
// problem is that it cannot inherit or use any polyformism.
// classes example
class Person{
uint age=0;
this(uint newAge){
this.age=newAge;
}
}
Person* p= new Person(12);
// You cannot just do this
Person p(12);
Person p=Person(12);
Cbindings
Its cbindings were quite simple to write, I didnt had a problem when integrating it with my program,
I will show you a simple example from my project
import std.string : fromStringz;
// I have this defined in a different file but this works as an example
extern (C){
ulong ERR_get_error();
void ERR_error_string_n(ulong e, char* buf, size_t len);
}
void OpenSslReadError(){
char[256] buf;
ERR_error_string_n(ERR_get_error(), buf.ptr, buf.length);
string msgError = fromStringz(buf.ptr).idup;
if (msgError.length > 0)
throw new Exception(msgError);
throw new Exception("Why was I called?");
}
Here is my dub.json
{
"description": "An abstraction to use some basic OpenSSL bindings, initially thought for PQC algorithms.",
"license": "MIT",
"authors": ["ranon-rat"],
"copyright": "Copyright © 2026, ranon-rat",
"name": "cryptod",
"libs-posix": ["ssl", "crypto"],
"libs-windows": ["libssl", "libcrypto"]
}
This is quite clean for my standards, it didnt gave me any problem and I was also able to use most types with it. And its linking with static libraries was also quite simple.
dlang environment(tools)
As I said previously dlang doesnt have the biggest amount of community packages but its environment and its tools were quite nice.
To install dlang I only needed to run one command(I use fedora)
Dub, it was simple to use, it was fast and it had everything I needed. it was like using cargo but faster.
Its documentation was great I had a lot of fun reading it, you can find a lot of interesting things and if you are someone that its starting to learning to code for curiosity then its something that you would love. Its comparable with the rust documentation.
I mostly work with codium because its lightweight and it has almost everything I would need, I want to eventually move to emacs, but for now codium is enough for me. To use dlang in my text editor I only needed to download the extension code-d, It had everything I would ask for it, the only problem I had with it was that sometimes it bugged for some weird reason but it kept its autocompletition.
Its package website was also simple, good enough for me to navigate and to publish a library it didnt asked much from me.
final thoughts
Its quite mature, flexible, and has a lot of interesting features. You can learn a lot from just reading its documentation. Its fun and has a lot of benefits which you could only encounter in dlang. Being able to have a garbage collector or to deactivate it in functions which you know that will work fine its quite powerful. It can be good for new programmers to learn it specially for how its designed. It feels like a language made with love and it can be quite fun to use it.
I had more fun using dlang than using rust, and I would probably use it more specially because rust even tho it reduces the possibility of any memory leak through its borrow checker, has RAII and other stuff, it forces you to code in a specific way which adds a lot of friction and another thing its that it can still leak memory, the garbage collector(which you can desactivate) can add a bigger layer of security when working for big projects.
And to work with others it can still be more useful because its more readable and it doesnt forces any kind of style and also because its easier for a c/c++ developer to start using dlang without having the deepest knowledge about the language.