Details to be announced.

D is a language with many features, but the whole has a character that can't easily be inferred from the traits of the parts. I will give a tour of how this character has let Symmetry build a strong “base layer” of code without becoming rigid or fragile.

D 2.0 added a new const system to the language. But half of that system—immutable—still often leads to errors. That's a shame, as immutable data structures enable more reliable, readable, and testable code. However, with some limited compiler abuse, immutable can generally be made to function. Here's how.

D offers many powerful compile-time and run-time features. One of the places to see how these features work together for great effect is Phobos, D’s standard library. This talk will dissect some Phobos algorithms and types to present how it takes advantage of D.

In this talk, I will go over everything related to D’s ability to interoperate with C++. We will cover design philosophy, limitations, as well as practical examples extracted from real-life usage.

D provides several significant advantages that allow small teams to punch above their weight class in the world of online services. This talk goes over several of these advantages including: reduced memory/CPU footprints, a richness of features allowing libraries from other languages to easily be converted, and several practical tips for deploying via AWS.

Bringing the D language maintainers on stage and grilling them with questions from the audience is a DConf tradition that the 2022 edition continues. Whether you're in the room or watching on the livestream, Walter and Átila will do their best to answer any queries you throw their way. So don't be shy. Start brainstorming now and bring it on!

Details to be announced.

Different hardware architectures implement different memory models. This in turn makes porting software between different targets an insanely complicated task. To solve this problem, C++11 introduced a language memory model that was later adopted by other languages such as D and Rust. In this talk, we will discuss the problem, the solution and why you still have to be careful if you want to maximize performance. In addition, we will consider ways to try and make atomic variables easier to reason about.

Structured concurrency applies the lessons of structured programming to concurrency with the aim of reducing software cost and complexity. This talk starts from the basics and builds up to the concept of structured asynchronous computation as implemented by C++’s Sender/Receivers. This can be used to build up larger patterns including event loops, asynchronous ranges, actor models, etc., and provides a flexible and composable way to write concurrent and parallel programs without the need for explicit synchronization or understanding complex topics like memory ordering.

Peter Shirley’s book ‘Ray Tracing in One Weekend’ has been a brilliant introduction to implementing ray tracers for beginners. While you may not have read the book, you may have seen the viral images of programmers all over the world sharing images generated from their ray tracers on social media. While the book is implemented in C++, I was up for the challenge to implement the ray tracer in D. With the efficiency of the D language however, I set myself the challenge to complete the task in less than 24 hours. In this talk I will describe my experience, highlighting features of the D language that made this possible. I will also discuss why D may be the right language to teach software engineering in a university setting for this reason.

“A jack of all trades is a master of none, but oftentimes better than a master of one.” D is multi-paradigm, which is sometimes considered a weakness: the language is spread thin, and making every feature work with every other feature is a complex task. Despite this, I consider it one of D’s strengths that low-level and high-level come together in one language. I’ll talk about how I use D in various projects of my own, from bare metal to high-level scripts, and why D is a suitable language for them despite their different nature.

Computers are faster than ever, software is often pretty fast, and yet systems are slow. I’ll introduce aspects of what the computer is doing under the hood while also explaining how to make sure you know when to care.

Programming languages seem to be sprouting up all over the place, building on solid foundations, rejecting perceived failures, and often breaking new ground. What are they doing right? What are they doing wrong? Where are they going in the future? This panel will discuss these questions and more related to the topic of programming language design, and will take questions on the topic from the in-house and livestream audiences. If you’re curious about the past, present, or future of programming language design, here’s your chance to pick the brains of four people who are designing and researching programming languages today.

Details to be announced.

GNU Bison is a general-purpose parser generator that enables a wide range of use cases, from custom Domain-Specific Languages to parsers used inside programming language compilers and interpreters. This talk aims to present the D backend for GNU Bison to a wider audience—it was officially introduced in Bison in the autumn of 2021, but this has not yet reached the wider D community. I will delve into how I continued GNU Bison’s experimental D parser, which was implementing the LALR(1) algorithm. I will present how I designed the API for D, how I implemented some key features, and the challenges I faced. If you are curious about how I interacted with the Bison project and my experience with SAoC, then this talk is for you!

D adoption has been hindered by the scarcity of development tools available in the ecosystem. One of the main reasons for this situation has been the absence of a proper compiler library that can be leveraged to develop tools. For a few years, a compiler library has exposed the DMD internals, but the interface is still lacking. To address this problem, I am taking a different approach by trying to integrate the DMD library into existing, successful projects. This project has two objectives: (1) developing a proper interface for the compiler library by leveraging existing use cases, and (2) updating existing tools to use the compiler library, thereby making it easier to update to the latest version of the compiler.

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

Lightning Talks are a set of 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 Talk session from DConf 2019 is a great example of the format.

Any DConf attendee can sign up to present a Lightning Talk. We’ll have 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.

In D, certain high-level constructs are lowered to calls to functions from DRuntime called hooks. This process takes place in the compiler’s intermediate representation generator. This has the following disadvantages:

1. The compiler doesn't verify the safety of the hooks, because lowerings take place after semantic analysis. This means that the hooks are essentially lying about their attributes.
2. The hook arguments are mostly void[] and require the TypeInfo hierarchy to extract type information at runtime. This is unnecessarily slow because all type information is available at compile time
3. All hooks are linked into one large runtime library that all D programs link, regardless of which hooks they use. This makes druntime unnecessarily large for use cases were a subset of the hooks is used.

This project eliminates all these disadvantages by converting all 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. In addition, this brings performance benefits since runtime checks are moved to compile time.

D’s perfection does not come from the language, but its standard library. The necessary migration from D’s self hosted Bugzilla to GitHub serves as a rewarding backdrop to explore this marvelous library.

Phobos is not always given the credit it deserves. Loud negative talk about its reliance on the GC or interconnectedness of its modules are nothing more than distractions from its expressiveness and comprehensiveness. The task of migrating all open Bugzilla issues to GitHub gives a very good opportunity to explore many Phobos modules and their interplay. This task requires everything from networking, to text processing and data aggregation. Many of those exercises are likely reflective of others’ daily work, and thus they would likely gain an understanding of Phobos if they are not already using it.

Walter Bright started the D programming language as a one-man show. After he pushed it out to the wider world, curious programmers started dropping by to check it out. Little by little, person by person, a community took form. They brought new ideas, bug reports, and patches. They built libraries and tools, wrote blog articles, and evangelized the language in other communities. Without those early pioneers, D as we know it would not exist today.

In this talk, we’ll journey back in time to get a look at where it all started, then move forward to the present day, stopping for highlights along the way. My goal is to show you why I’m an eternal optimist about D—no matter the state in which you first found the language, it’s always better than it used to be thanks to the efforts of the amazing D community. We’ll wrap things up with a look at how I would like to see the community and the ecosystem evolve in the future.