Dub is an amazing tool, but due to its features not being segregated enough, it can be difficult to contribute to the project and to identify bottlenecks. Redub is a tool focused mainly on building. It brings compatibility with dub, faster build times, and rewards good project structure.

In this talk, I introduce the new tool and various aspects of its usage, including but not limiited to the motivation behind it, the base development plan, comparisons with dub and reggae, and more. My goal is to help D users discover new best practices that could benefit the entire D ecosystem, and to thing more about public and private dependencies.

We’ll devise together a tautologic, all-encompassing, theory of software that posits a composable economic value to every piece of software, however small.

Through this lens, we’ll see in equations:

This theory has no predictive power without a cost heuristic (else you would need to see the future), but the hope is that it’s useful nonetheless, or at least entertaining.

After an epiphany, I finally found it: the perfect memory allocator. Last year, I talked about stack memory and its limitations, but I've found a way around them. Now I have a scheme that combines the best parts of the Garbage Collector and manual memory management. It’s @safe, it’s @nogc, and it’s implemented in only 80 lines of code. The gist of it is that pointers to arenas are passed to return scope function parameters with default arguments. How it works exactly will be explained in the talk.

In this talk, we show the key role of the D programming language in the development of a task-based parallel programming framework for a novel compute-accelerator platform. The platform consists of a set of compute accelerators (like GPGPUs) and a management processor. The management processor’s role is to orchestrate the parallel execution of kernels on the accelerators. Using the D language for the code running on the management processor allowed us to write high-level, size-efficient code.

The key features of D to achieve this are extensive use of templates, interoperability with the underlying FreeRTOS written in C, and BetterC. Since this is our first large project in D, we will also share some concrete highs and lows of using the language. Next to that, we discuss the generic user experience of D and lessons learned.

This work has been carried out in the ExaScience Lab of the CSA division at imec. Special thanks to Robbert Gurdeep Singh, Geert Vanmeerbeeck, Wilfried Verachtert, and Roel Wuyts

In D, certain high-level constructs are replaced with calls to lower-level functions from DRuntime, called hooks, that provide the same functionality. This makes the compiler’s job easier by saving it from having to generate code for complex expressions itself. This process takes place in the compiler’s intermediate representation generator. This has the following disadvantages:

This project eliminates these disadvantages by converting DRuntime hooks to templates and moving the lowering logic to the semantic phase. Thus, all new hooks are verified to respect the restrictions imposed by attributes, type information is leveraged at compile-time, and D executables will only contain code for the hooks they use. This brings performance benefits since runtime checks are moved to compile time.

As time goes by, best practices evolve, needs change, and better ideas have appeared. What began as idle conversation in late 2023 has become a full-scale effort to forge the future of Phobos. Today, Phobos 3 has been under active development for 6 months and the ground-work for the future has been laid. But what does this mean for Phobos 2? What will be included in Phobos 3 and what will be cut? What comes after Phobos 3?

In this talk we will discuss where Phobos 3 stands today, what work still remains to be completed, and finally where we want to take Phobos in the future. The goal of this talk is to provide a roadmap for all D engineers as they begin planning for the transition to Phobos 3.

When you think of parser/AST/visitor generators you normally think of classes, polymorphism, and pointers. This is, no doubt, the reasonable way to approach such a project. More fun can be had, though. Maybe we can even improve on things by not following the standard way, but having fun outside of the box.

In this talk, we therefore explore what happens if we do the interesting/fun things instead of the reasonable, standard, boring things. These things include data-oriented design, array-based trees, bitmaps, and exploring hardware oddities.

Buck2 is a shiny new declarative build system from inside Facebook. I have been on an adventure making it speak D. As such, I will describe writing D rules in the ‘starlark’ build language that it uses, and then pontificate a bit on declarative build systems (at both micro and macro scales), toolchains, meta-build systems like reggae, and loop back around to dub.

In a world which can’t be stopped, we need a new hero. (Well, maybe we can stop it for a few microseconds...) In any case, the current garbage collector for D has been relatively stagnant in design since the development of DRuntime. We have had a few nice improvements, including fork-based, parallel scanning, and precise scanning. But we can do better. Our ideas on how to improve the performance of the GC get down to the lowest level of the hardware of modern systems, and try to squeeze every last bit of performance from the GC.

This talk will delve into the details of why we need a new garbage collector, and how we can exploit modern memory and CPU architecture and use clever storage techniques to streamline GC allocations.

Have you ever tried to create life? Of course not! You’re not a god. But you could try to simulate life in a computer as many scientists have done. I’ve been doing that in D for months.

I’ve ventured into the world of biology simulation, I’ve created a simulator where you can set up an environment in which you can watch organisms interact and evolve. This could be used for research, educational purposes, and fun. It was written purely in D. I’m striving to make it the best biology simulator in the world. Come watch my talk to learn more. I will talk about some evolutionary concepts such as RNA, DNA, natural selection, and biophysics, and I will be demonstrating the software as I explain in detail how it all works. Before the conference, feel free to watch this video that includes a demonstration.

Fluid is a library for building general purpose graphical interfaces. To communicate the desired layout and style to the program, a common language has to be used. I will compare solutions used in different frameworks, explain D's advantages in declarative API design, and its significance for user interface programming.

One of D’s goals in its interoperability with C++ is to be able to use some of the major C++ Standard Template Library from D. In this talk, I will reveal where we are in this process as a language. I will also cover real-life usage with their design philosophies, limitations, and the way forward in reaching seamless C++ integration.

A new version of D’s standard library, Phobos, is currently under development. We would like to fix some of the mistakes that have been made over the years which we haven’t been able to fix without breaking code, and we want to update Phobos according to the current best practices for D. Ranges are a big part of Phobos, and they are are being reworked as part of the update.

Overall, ranges have worked very well for us since they were first introduced in Phobos v2. We would like that continue, but there are some issues with their current design which have come up over the years. We’re taking advantage of the opportunity Phobos gives us to implmeent otherwise breaking changes by improving upon the existing range design and fixing mistakes. This talk will go over the changes and why we’re making them.

D ships with dustmite, a tool that lets you take any D project with an issue and reduce it to a testcase. But using dustmite effectively requires some experience. Having filed many bugs with dustmite reductions, I will share reduction strategies and gotchas.

Just when you thought we were done with GC talks, we have more for you!

In this continued presentation about the new GC, we will talk about how we organize small allocations to reduce fragmentation, how we avoid lock contention when allocating, and how we optimize collections to take as little time away from your code as possible. We will also talk about integration with DRuntime and planned future improvements that can bring this new allocator further into the realm of modern GCs.

D deserves to have a GC with few pauses and high multi-core performance. We hope to bring you that experience.

Got something interesting to tell the D community, but not interested in presenting a full talk? We’ll give you five minutes to tell the world!

Lightning Talks are presentations restricted to five minutes or less. Speakers plug in their laptops and get started immediately. When their time is up, the emcee pulls them off stage and the next speaker gets going. The Lightning Talks session from DConf ‘23 serves as an excellent example of the format. It even included a stand-up comedy routine—a DConf first!

Any DConf attendee can sign up to present a Lightning Talk. We’ll have up to nine slots available this year, and we’ll fill them on a first-come, first-serve basis. Email social@dlang.org anytime before the conference to reserve your spot (after you’ve registered), or let Mike Parker know at any point during the conference prior to the start of the Lightning Talks session.

The D programming language and ecosystem provide many modern features which can help give developers a competitive advantage during the software development lifecycle. In this talk, I will discuss how D provides a competitive advantage for graphics application development (e.g., games, rendering), where any reduction in iteration time can improve outcomes. As an example, when creating an art style, having systems allowing rapid iteration can help improve visual fidelity, both in aesthetics and correctness of the application.

Throughout the talk I will showcase visual examples, developed in a summer, that show off a graphics engine built completely in the D ecosystem. Topics will include: a hot reload system, a job system (using concurrency), and showcasing the architecture of a small graphics engine. This talk follows up a previous Dconf Online 2024 talk in which I make a case for using D for graphics programming—this time showing you the results (attendees need not have watched the previous talk).

D-Scanner is one of the most widely used static code analysis tools for D. It relies on libdparse, a third-party D parser implementation. As a consequence, every time the D frontend is modified, both libdparse and D-Scanner need to be updated. Given that D can be built as a compiler library, replacing libdparse with DMD-as-a-library will make it easier to tackle compiler updates.

Over the past year, I have embarked on a transformative journey within D-Scanner, tasked with migrating from libdparse to DMD-as-a-library. In this talk, we will explore the migration process and address the challenges of keeping up with DMD-as-a-library, integrating with upstream, and maintaining trustworthy tests.

D has historically been open to the addition of new features. While some of have been net benefits to the language, others simply offer some sort of convenience while either increasing the codebase complexity or enabling patterns which are hard to maintain. This talk will present a series of such language features, exhibit the impact of their implmentations on the D codebase, and explore the alternative of removing them.