This Week in D July 3, 2016

Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.

The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.

This Week in D has an RSS feed.

This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.

Statistics

Major Changes

DMD 2.071.1 was released this week. It is a bugfix release that fixes at least 15 bugs.

DIP25 (sealed reference detection) bugs are being fixed in dmd git, Walter is hoping to enable it by default soon.

Phobos got a lot of small pull requests to unit test @safe and @system explicitly, to ensure they compile properly with memory safety verification expectations throughout.

GC implementation swapability was merged into druntime.

In the community

Community announcements

See more at the announce forum.

Project Spotlight

This week, I want to talk about my own cgi.d.

I started writing cgi.d back in late 2008 on the weekends while working primarily with PHP on the weekdays. I wanted a solution that shared PHP's biggest strength, ease of deployment and writing quick pieces, while fixing many of the problems I was struggling with at the time, such as mutable superglobals.

I had already been using the D language for a couple years at that point on home projects such as games, but had never attempted to use it on work or other web programming. I was fairly familiar with the CGI protocol, and played with it in C++ in the past, but never found it good enough to use - I preferred even PHP.

The first draft looked nothing like the current version. I used a module constructor to load up the variables into globals, just like PHP. D didn't even have immutable at the time, but use of final got close enough to help mitigate the problems I was seeing in PHP.

While this worked, I wasn't really happy with it and didn't do any real work with it. I tabled the idea for a while.

Around the end of 2009, D was getting a new feature, then called invariant, which would later become known as immutable. This was a MASSIVE breaking change, but an exciting one as it seemed to enable all new ideas. I went back to the cgi.d idea and started refactoring it into the shape it has now: a class Cgi with immutable members for common web parameters.

This was getting usable! The new invariant/immutable feature was rapidly changing. In the first version it appeared, string literals were immutable, but most other strings in the language were still the mutable char[]. I briefly played with the idea of using this to identify literals for SQL injection and XSS detection, but before long, the language transitioned fully and this was no longer useful. I needed some surrounding infrastructure. I started mysql.d in 2009, a project to wrap the MySQL C API as a simple D class. It wasn't terribly useful, but I was able to get it working quickly - a big confidence booster that this was realistic, I could do all the tasks I needed to do, and if something new came up, using existing C libraries took only a small investment with quick, reliable payoff.

Coincidentally, in 2010, I started writing dom.d. My original intention was to play around and not use it for anything serious, but once I had it working, it quickly became both a playground with D's emerging features as well as a solution to my XSS concern: instead of building strings, I'd build a DOM tree and print that out.

Of course, that's not the only way to use cgi.d, it's interface was deliberately kept uncoupled, simple, and generic - it just dealt with ordinary arrays - but the combination of the two plus mysql.d was enough for me to put D over the edge as a language I could seriously use for the web... so I started doing day job stuff in parallel. On the weekdays, I'd write it in PHP, then on the weekend, I'd reimplement it in D and see how it compared.

$(P After only about two months, we are now in mid-2010, I had enough to show to the client: the D version had feature-parity with the PHP version... written in about half the hours. As the PHP app grew, making changes reliably became harder and harder, whereas the D app scaled more linearly. As gravy on top of the superior long-term development curve bending, the D also performed better than PHP as the program grew (though it did lose on small benchmarks of scaling as PHP beat the CGI overhead on simpler programs, this advantage disappeared with a more complex program). The main benefit, however, was always my productivity in the environment of rapidly changing business requirements.

The client gave the go-ahead to actually make the transition going forward for new components, including a major new project coming in the pipeline as long as I maintained compatibility with PHP so if something went wrong, we could plug it right back.

I wrote some IPC and session reading code to handle the PHP interop and was off. I was officially a professional D web programmer at this point. A good chunk of my arsd repo on github is the open sourced support infrastructure for the work programs I'd write over the next four years.

cgi.d still had many changes coming - multipart/form-data for file uploads, FastCGI and SCGI alternate interfaces to reduce the CGI overhead even more, and today it even includes an embedded HTTP server for simple development or internal deployments (I still STRONGLY recommend using a real http server with a reverse proxy or one of the CGI options for production, web-facing deployments) - it has grown far beyond just being a cgi helper library like its name implies.

Moreover, my addon library, web.d, was an early adopter of D's reflection, giving a lot of automation to cgi.d's boilerplate. I'll write more about it later, but now when I go back to PHP, I more often emulate web.d than my old way of making D emulate php.

cgi.d today, eight years after its initial draft, is my go-to tool for making non-trivial web applications. I still actually kinda like PHP for really small things, but if it doesn't fit on one screen, I'll write it in D and my old, reliable cgi.d is how I'll do it. Using a simple process model and C libraries instead of new techniques like vibe.d's fibers may make me a bit daft, but it also keeps that confidence from early on: my libpq wrapper just works. My mhash bindings just work. I've spent years interfacing with a variety of real world systems and haven't needed to rewrite popular libraries (though not *needing* to doesn't necessarily stop me :) ) and I am happy with it just how it is.

Learn more about D

To learn more about D and what's happening in D: