Hello.
All right.
Great to see everybody.
See some familiar folks here.
Just a quick show of hands here.
How many folks have heard about the D programming language?
Oh, wow, awesome.
Keep your hand up if you've used the D programming language or tried it out.
Okay.
Yeah, I see you there, Dennis.
Yeah.
A few other folks here.
Great.
This is perfect.
You're in the right space.
We're going to have a lot of fun today.
And I'm going to give you an introduction to the D programming language here.
I'm not going to show you everything because the D programming language is a really large
programming language, but hopefully enough to get you excited here.
And ultimately to show you some open source projects where you can get some inspiration.
So let's go ahead and get into it here.
So again, it's been six years since my last Boston talks.
I just want to thank the organizers for inviting me back and letting me talk again.
So again, the goal today is just to have fun.
You can kind of sit back, relax, have a good time and just learn about, again, what I think
is really interesting programming language that's expanded my mind as far as how I think
about programming.
So with that said, hopefully I'll come back sooner than every six years.
So a little bit about me.
My primary role is to do teaching.
So I'm an associate teaching professor.
So I love teaching stuff.
I do teach the D programming language.
I'll talk about that towards the end or give you a reference for that.
Otherwise, I'm really interested in other sort of performance systems, these stuff.
Again, you folks are my crowd.
So again, I'm really excited to be here with you.
And with that said, here's the abstract, of course, that you read and led you here.
Again, to get you excited about the D programming language.
And any code that I have for the talk will be linked here.
If it isn't already shortly after this talk, I'll post it.
All right.
So again, what I want to do today is, again, get you curious about a really, really cool
open source project.
Now that open source project happens to be the D compiler.
In fact, all the D compilers that we're going to find out have the source code available.
So how cool is it that you can actually look at a programming language that's been around
for quite some time and see some really awesome work by some really smart engineers.
So at the very least, I hope that's exciting for you that you will have some place where
you can look or send other people to look and see how optimizations are done or code
is written or organized.
So again, I think that's in itself very interesting.
And maybe one day you yourself might find yourself contributing to this compiler, this
ecosystem, or find inspiration elsewhere for using this programming language.
And again, my secret dream for you, if I do a good job during this talk, is to get you
excited enough to say, yeah, I'm going to contribute.
There's been some awesome videos on how to just do that.
Again, a lot of the open source projects that we've seen today and we'll see tomorrow have
these resources.
So again, I just want to point out that those are available as well.
So again, it's really cool to look through the source code of the D compiler, which is
a very, very, very fast compiler for the D programming language.
Okay, so with that in mind, with my interest out there on what I want you to get out of
this, or maybe to get excited about, again, whether you're a student practitioner, somebody
in industry.
Again, we'll continue moving forward here.
And as I'm talking about this, I do want you to know that I'm a bit of a programming language
enthusiast myself.
So I love using different programming languages.
This has been a problem for me since I started programming, always looking and kind of moving
around to different languages, seeing what was new, what kind of features.
And honestly, I think there is some value in that.
You get to see how different languages approach things.
Actually, we were just at a previous talk on the Hector script talking about actor model
and mutability, how parallel processes are organized.
I think there's a lot of value in taking away some of those core concepts from different
languages.
So what I've been doing lately is, again, every few days now at this point, I've been
just turning on my camera for an hour and live streaming myself, learning a programming
language for the first hour or so.
And you pick up interesting things from different languages.
But just to be clear, the languages that I use professionally and teach most are C++
and the D programming language.
I'm always kind of thinking in terms of, oh, you know, Golang does it this way with their
defer statement and D has scope, or oh, there's message passing in this language and this
is how you do it in D in this way.
So it's been a really interesting sort of experiment going through this process.
And I'm thinking in the language that you ultimately, well, use.
You kind of wire your brain a little bit sometimes.
So that could be something kind of curious, again, looking at new languages, looking at
languages that are popular, looking at languages that are maybe not so popular as well as far
as mainstream.
At the end of the day, what I hope one of your other takeaways will be is, you know,
as we know, sometimes it doesn't matter what the language is.
It's going to be what gives you a competitive advantage, what is fun for you to build software
in, what is, you know, the tool that you can use to create something.
So then my goal is not going to be to convince you today one programming language is better
than the other.
Even as I look at those programming languages, I try not to do that.
I'm smarter than that.
I think I am.
We'll see if I slip today.
You know, we sort of like our program languages and get used to it, right?
We have our favorites.
But again, I do want to share my enthusiasm for D, why it stands out, and why you might
also have fun with it.
So with that said, we're going to do that same little experiment that I've been doing,
just turning the camera on for an hour, looking at a programming language for the first time,
and just investigating some interesting parts of it.
I hope that will get you curious about the different parts of the D programming language
and again get you excited.
And maybe, just maybe if I'm successful, and I looked around, I saw everybody who rose
their hand and who didn't.
We'll see more hands raised.
What was it?
Six years from now when I'm invited back.
So anyways.
All right.
So I'll show you a few cool projects for inspiration.
Most if not all are open source.
The only ones that aren't are the scripts that I haven't put in my GitHub repo yet.
So we'll be true by then to this top.
And all something that you can learn from a specific feature.
I'm a big proponent.
Again, my background being in teaching in some industry, that we need to read more code
as we're learning as well, because there's lots of smart engineers, you folks, writing
that code and I want to learn from you.
So with that said, we'll look at these projects all in the D programming language here.
So let's go ahead and begin.
I'm going to go ahead and start with something cool made in D. Why not get some inspiration
to start this talk off.
And here it is.
A project that's built in the D programming language.
TILIX.
How many folks have used this terminal emulator?
Yeah, I'm seeing a few hands go up here.
Yeah, this is something I like to occasionally download and try out different ones.
But to my surprise, I actually looked at the source code.
One of my students actually told me TILIX is built in D. I didn't know that.
So that was really cool what you find sometimes in the wild.
But again, oftentimes as a user, you don't really care.
Just a cool piece of software as an end user.
But you get to see as a practitioner some of the cool tricks they do.
So along with just showing you some different tools that have been built in the D programming
language, I think it's important to say, well, why don't we care to look at this closer?
So with all these slides here, again, I'm not going to ask you to read these or click
on all the links.
The slides will be available.
But what you might be curious about or with this particular project, what's interesting
is to see that, well, it's something that's very visual.
And if you dig into the source code, it's using the GTK libraries.
And those are C-based libraries.
So how does D interface with C code?
Well, the answer is D actually does a really, really nice job interfacing with C code.
So if you are C programmers or have been using C, you can basically call directly your C
functions in the D compiler.
Easy as that.
Now, of course, there are bindings and wrappers and other things that folks do with the D programming
language.
But that's nice.
You get a head start by being able to use some of your C code or even C++ and Objective
C. There's ways to squeeze stuff in.
So I thought that was very neat, just looking at the main app file from this particular
program to see the different libraries that they were bringing in and was it just straight
C code or library?
Some other neat things that I'm just going to trickle in some details about the D programming
language as we go along here.
There is something called import C, which is a really cool, well, it's effectively a
C compiler built into D.
So you can, on the command line, like you would with whatever your tool was, type in
compiler, DMD, your D source files, and your C source files as well.
So that's kind of neat there.
Again, just giving you a head start if you're going to consider migrating to different programming
language, which is a big decision to make if you already have some open source project.
All right, so that's Tylix.
That's kind of a fun one.
I'm learning about how D can also play with C code.
Okay, so let's just get a first impression of the D language.
Again, pretend you're doing this experiment that I'm doing.
You go into Google, you type in Dlang, and you go to the homepage, Dlang.org, and what
do we see here?
We'll actually see something that looks like this.
I'm going to give everybody a minute or so to just look at this piece of code.
There's a sample code there.
And then I'll ask for some participation.
We can make this interactive on the afternoon.
But just take a look at this and let me know what you think it does or what's interesting.
I'll take hands and get some volunteers here.
I'll give everyone a minute to think about that.
What's popping out there, folks?
Give me a hand and then something out.
Yeah.
So the few things I see on the first line, the import is local to main.
On the second one, there is an object-style notation for a string.
On the third one, there is an enum for an array, so that one I don't get.
Then there is this immutable keyword, which is interesting because it's doing a mutable
operation on A, but then B is immutable, I guess.
And MSG is apparently a program that you send to the compiler, so I suspect it emits something
at the end of compilation.
Okay.
How many did I get?
Yeah, so we got a good staff at it.
I saw other hands going up here.
There was one actually right behind, if you wanted to share.
Yeah, it could be the same thing or to add on.
It really looks like a C, next one, like a C+++, free plus, so I don't know why they
gave a name D, but they could just keep it with the pluses.
In a way, it's really kind of easily to read.
If you know anything of C or family, you can easily jump in and just do it.
Yeah.
So immediately when we're looking at program language, just to recap, we see it's sort
of a curly brace, C style, algo style language, right?
So we can kind of read it if we know C or C++, objective C, whatever.
And it does look like a C+++, kind of language.
We'll talk about that in a second.
There's another hand here.
Is that program manipulating types as values at compile time using decode like you would
do in the ZIP program language?
So the question about is it manipulating types here?
Or something's kind of interesting about the types, certainly here.
So for instance, what's the type of B, for instance?
So what's it doing with the types there?
Okay, it's static.
We sort of know static and C and stuff, something about memory storage.
Immutable, some sort of qualifier.
It turns out a stronger than const.
But what's the actual type?
Well, there actually is some types being inferred here for us, like auto and other languages.
Now I will let you know, again, I'll repeat some of these details.
D is statically typed, but at compile time, yeah, we do have to make a decision about
what the actual type's gonna be and what's returned.
Yeah, this is great.
I'm gonna advance it one slide forward here, and you'll see what the label is on the program
here on the D language homepage here.
And it's sort of an array at compile time.
And that's kind of cool.
Just this first example, this is usually the first example that comes up here.
And I've got a description of the stuff that you folks recapped very nicely.
But let's actually, we'll run or look at a few codes, but
I think we should at least look at this basic one here.
Let's make it a little bit bigger here.
Just to get a feel, again, this is the same Hello World sort of program.
Well, this is maybe even after Hello World, I would say.
But interesting enough here.
And let's just go ahead and compile it.
So with DMD, again, I'm looking towards the bottom of my terminal here.
I'm gonna compile it out.
This program I called compile time sort.d for the extension.
And the output file is going to be prog or prog.
And as soon as I hit enter, interesting here.
It's finishing compilation here.
And boy, I didn't run the program.
I'll tell you I didn't run it.
But while I was compiling it, yeah, there is something interesting here going.
It is called compile time sort.
So you might have guessed that.
But interestingly, and this is one of the big, why should you care?
Or things to look out in languages that you care about.
We can do computation at compile time.
So this is a really powerful feature of the D programming language,
the D compilers specifically, that we can take something like in a new,
something that would maybe be a constant, right?
Usually in another language.
Set some values here, like an array.
And then actually evaluate it with sort.
But again, if you look at sort, this looks like a function that you might just
call in your regular programming language, right?
So there's nothing really different than the compile time sort to the run time sort.
That's probably what we want, right?
To be able to execute as much as possible at compile time and
save our work for when we're actually running, right?
Before aiming for performance.
Of course, there's always trade offs for that.
You notice that might take a little longer to compile.
Again, let's go ahead and compile it.
Again, pretty fast.
Actually, we're gonna talk about how fast the D compiler is later here.
Now if I actually run it, the program here, PROG, right,
we just get hello, Fostum, because that's the actual run time computation that's
going on, okay?
This part here, this is the only thing we're really doing at run time.
Now if we go on and later do something with B or print it out,
we'll get to our sorted array, but that's the point there.
So, already kind of neat.
This is kind of an attention grabbing thing.
And again, something that might be new depending on what programming languages
you've looked at.
And the thing, again, one of the things that certainly caught my attention.
All right?
And I mean, there's some other interesting stuff here like the,
I think was mentioned here, the quoted string before, right line, dot right line.
Okay, we'll talk about this.
It's called universal function call syntax, but
you know, some nice potential quality of life features for us.
All right, so that was our pop quiz, only pop quiz we have here.
But I do invite folks to raise their hand high if they see something interesting
as we move forward.
All right, so again, the sample and why you might choose to care.
Just to go back, we call this CTFE or just Compile Time Function Execution.
This idea that we can do work at compile time.
Didn't we know there's a lot of other languages, templates, or
sort of a mechanism to do this if you're coming from C++ background.
To various extravagance levels of metaprogramming that you can do.
Other languages might do this a little bit more explicitly otherwise, but
that's the idea with the decompiler.
So a big win in my mind.
In a big win, how clean this syntax is.
Okay, so a little bit about this deep programming language.
Somebody mentioned, it kind of looks like C, plus, plus, plus, plus.
Yeah, so a little bit of history here.
Walter Bright, who's highlighted there with the arrow, that's him at D-Comp.
A few years ago, two years ago now.
He was the initial creator of the deep programming language.
It's called the Digital Buyer's compiler originally.
But folks kept saying, hey, it looks like C++, plus, plus, or whatever.
And they just started calling it D, and that just sort of stuck.
So that's what we got here.
So a little bit about Walter, again, he's a compiler expert.
He's worked on C compilers.
Hence why there's sort of a C compiler in the D language.
C++ compilers.
And then of course, thought about it for a while and said, well,
I'd like to make something new, something that's fun and efficient to program in as
well, and that's where D sort of came about.
And then also, a major collaborator was Andre Augsindrescu,
around 2006 or so, joined.
And then for the next 10 plus years was a very active contributor in building what
we now use as D2.
And we actually got other audience members who are contributors.
I don't know if you want to out yourself, you can raise your hand, but you don't have to.
So anyway, so there's a full history with the D programming language and
a really interesting article if you want to learn about the history and
the origins about how to evolve and the sort of why's you do things in the programming languages.
Again, that can be interesting sometimes if you know the historical context,
why things look a certain way they do.
Sometimes that helps you understand when or when not to use a feature.
So anyways, that's just a little bit about the history of the D programming language here.
So again, what is the D programming language?
Still on the front page, it's a general purpose programming language with static typing.
So whether or not you see those types, they can be inferred.
It's a systems level programming language.
So you have low level access to things like pointers, for instance, and
you get the C likes syntax.
So it's relatively familiar again if you've used C or C++, right?
I imagine pretty much everyone who knows I hand who had heard of it's new.
Yeah, something like the next C or whatever.
But the mantra with the D programming language, at least on the home page,
is write fast, read fast, and run fast.
So we'll try to see if it holds up to those things and
again why it might be a good choice for playing around with or
maybe your next open source project.
So over the last 25 years now, there are three compilers for D.
There's the DMD compiler, that's the main one that Walter has and works on.
And that compiler is completely open source.
So you can dig into it, you can make a fork of it and modify it and
play around with that DMD compiler.
And it's a very, very fast compiler as far as compiling your code.
So you can compile the actual D compiler, I want to say in a matter of seconds,
tens or hundreds of thousands of lines of code.
And that has in part to do with these module system,
being able to do concurrent builds and how many passes it does over the language.
But it's very, very fast.
Your edit compile and run cycle is very quick as you're iterating and
doing development, which I find something important.
There is also the equally as important the GDC front end for
the GCC compiler suite.
I think it was around GCC 9 or 10 that was added in officially.
So you've got the front end there with Ian Buchwald working on that and
LDC work on by Martin, which gives you all the LLVM infrastructure.
So if you're trying to target lots of different platforms, for
instance, the LDC or the LLVM based D compiler is available for that.
So you've got three compilers, which is great.
So you don't have to worry about it disappearing anytime soon.
And it is very common for D programmers to take advantage of the very fast edit
compile cycle with DMZ.
And then when it comes time to build an optimized build,
you want to take advantage of all your GCC tool sets and infrastructure or
your LLVM infrastructure and all the optimization passes.
You can use those compilers afterwards.
So as far as downloading the tools, don't need to spend too much time on it.
But again, if you're on one of these platforms,
you probably have a way to get the D compiler built for that platform.
Or otherwise, there is a zip file or
something on your package manager available.
And with the D programming language, you get a package manager that's called
dub, which will help you manage dependencies, bring in packages, and
these types of things.
It's also sort of a lightweight build tool as well.
There's other tools that you might expect, like Dformat,
which are being worked on and already exist for code formatting.
Dscanner, which is like a linter.
And if you're a VS code user and want to intelligence and
these types of things, there's support for that, as well as for IntelliJ.
Okay.
So D, where is it being used right now?
Again, we've heard of this language.
Maybe we've used some of the applications without realizing that they were
written in D. Again, from the website, lots of different companies have used it
internally.
Again, folks like myself just use it for our own projects or research.
But I think D has done a really nice job finding itself in various performance
based niches.
From some of these various companies, there's different stories about
how different tools were being used, which I'm happy to go into.
So I want to go ahead and show a few.
And this was another built in the deep programming language tool.
I tried to pronounce it correctly.
I think it's Elmer, but it's a compressible flow simulator.
Okay, super cool.
So they're doing computational simulation, something very expensive to do.
So this tool now is 10 plus years old,
being used by various PhDs and postdocs and researchers.
But again, why should we care about this tool other than it generates really pretty
pictures?
Their website has some really beautiful pictures.
These are just the ones I sort of understand.
So I could post in case anyone asked a question.
But again, it's a project that's been around for 10 plus years.
Most of the code is in D and it's shelling off high performance.
And I thought this was a great message to share from their GitHub saying,
our focus is on open source development to give a simple access point for
doing their gas dynamics and research and teaching.
So what a great place to start if again you're in this area and
want to look at some open source D software.
Okay, so that's a nice tool.
Getting back to some of the D language features.
Sort of already thrown out one of the main big ones here,
the compile time function execution.
Which again, we're starting to see in more other modern languages, but
that's sort of a staple of D and why I think it's really interesting.
But the language itself has a lot of really nice quality of life features.
So these are things like you get a bunch of built in data structures
without having to import anything.
Dynamic arrays, associative arrays or maps or dictionaries.
They're bounds checked, which you can enable or disable.
There's always a path to performance here.
You get things like your land does and delegates.
The object oriented functional style, generic programming designed by
introspection, concurrent paradigms, all of that.
Again, they said it's a really big tool.
We can't cover all of it, but there's probably something interesting here for
you or it's a domain where you might expand.
I personally found that I started doing more functional style programming when I
started using D because it was very accessible in their standard library.
The D language also by default is garbage collected.
But you can turn that off if you want.
You can malloc and free.
You can do reference counting.
You can implement from scratch your own strategy if you want.
There is a question and I'll repeat.
Yeah, so the question, just to repeat and I'll break it into two,
is how granular are these, this ability to turn off things like garbage collection.
If you do need performance in a certain sectionary code.
That's as granular as putting an attribute on the function.
You could say at no GC on it.
And in practice, no garbage collections will happen.
And you can do that.
You can do that.
You can do no GC on it.
And in practice, no garbage collections will happen in that section there.
I think there are more in the actual tools you can do like a GC.disable,
which I think is similar to what Java and other languages have.
I think you could do like a system.noGC or whatever.
So you get that granularity.
That could be at a function based level, saying this code, no GC, and
being able to handle it.
The array bounds checking, I know that is set as a compiler flag.
I don't know if, for that one, I actually don't know the answer if you could do that
on a per function level.
What I would say is if you wanted an array that wasn't bounds checked.
There is, I think, of a standard library.
I think one of the standard array containers doesn't do allocations.
And then I would also just say, so you don't have to worry about that container
of garbage collections.
But for the bounds checking, I would probably just, to be sure,
you could implement your own dynamic array.
No problem, just like you wouldn't see if you want that granularity.
I will also show, what will I show here?
Yeah, so does that answer the question?
GC as granular as garbage collection per function, you can enable, disable.
And then for the array bounds checking, you can always implement your own.
But there is a compiler flag for on or off.
And typically, folks would use that again for that last little performance game,
if they're like building a video game or something, and super certain,
there's not gonna be any arrays that got bounds.
Because typically, you know the thick size allocation, you would just turn that off.
Perfect.
All right, questions or features that look exciting here?
And there's lots and lots, and the point is you have control, which is really,
really cool for what you need.
And we're gonna even dive a little bit further into this.
There's some other cool stuff you can do, if you only need a subset of this feature.
But let's continue getting inspired here.
So we've got a standard library.
So again, batteries included, like pretty much every other programming language
these days, you have to have a standard library with containers or data structures,
various algorithms, right?
We've already seen sorts in the very first example, but there are things like map and
filter and fold and so on.
There's various concurrency primitives and so on, and we'll take a look at some of those.
So you have a pretty decent standard library here.
That's in discussion about expanding and refactoring and so on.
So most of the common stuff you would need, handling JSON, CSV, files and so on.
So that brings me to another built in D here, why do we care?
I'll get into my code, so B's, Yanmi.
But so here's just the type of way that I started using the D
programming language was writing these little scripts, 50 line, 100 line,
throw away codes to automate some tasks that I'm doing at my desk.
I found myself doing a lot of queries to YouTube to gather data about what videos
have been published in a channel or what videos are in my playlist, these types of
things.
So what was really nice was just to find that there is the standard.net.curl in
the D standard library.
And then I could just build a query string and then effectively make a query and
retrieve my data from that curl request.
And then I have standard JSON and then I can just, again,
if I'm retrieving from some API, JSON data, again, common format for that JSON or
JSON, then I can work with that data as needed here.
And then you've got other sort of quality of life things like range-based loops.
So you can go through the keys, you can put the keys and the values here if you
wanted to iterate through them as well.
So nice little script you end up writing a few of these here.
So there's one example with YouTube.
I do this a lot for GitHub for, again, pulling repos, looking at them,
pushing code to students.
So again, same sort of pattern that I'm always using with any rest-based API
where I'm pulling data in.
One little interesting thing here, looking at line 53,
we can start to see that if you want to set various event handlers,
again, here's just a little example of a lambda function here.
You can have anonymous functions.
You can have delegates and these types of things in the D language.
So nice little quality of life things here.
Okay, so this is kind of interesting here.
My little scripts, and I'm sure many of you folks have your shell scripts or
Python scripts or whatever.
And again, that's what happened to me.
I had a bunch of shell scripts.
Mostly I had scripts in Python.
And then I just started translating them to D because again,
I liked it, it was a little bit less cognitive overload for me.
Again, if I'm working in C++ and D, they're pretty similar in how I can
think about some of those intakes.
But it's sort of interesting that when I'm using D,
I'm still effectively executing my scripts like I do in Python.
Okay, so let me go ahead and explain this here.
And what do I mean by that?
Yeah, question first.
Let's see, line 54.
Maybe a bug or something there, line 54.
Sorry, I didn't hear.
Unreceived.
Oh, the E and the I backwards, uh-oh, okay.
I knew I shouldn't have put my code here.
Good catch, I'll fix it in the post, yeah.
Gotta do some fixing tonight.
But the good news is, right, we can iterate quickly.
So I'm gonna give you an even faster tool that I use to iterate and run these
scripts.
Just a little helper tool, it's called rdmd, run,
you know, the dmd, basically just does on the fly compilation.
And it does, you know, it compiles, you know, as fast as your
decompiler basically does, dmd, but then it'll just execute your program
immediately.
And the advantage of this is then you can use D like a shell scripting
language, right?
You can actually, if I get a read down here, I'll try to highlight my cursor.
I know it's a little bit small here, but you can just put the pound
into the bang sign slash user slash bin slash environment, rdmd, you know,
chmod, execute, or whatever, and then you just run your program,
just like a regular script.
So again, that's a really nice way to, if you need to, transition your
scripting language to something that's statically typed, or you can just think
in the deprogramming language rather than multiple languages.
I found that as a nice quality of life improvement.
Again, I understand I'm the enthusiast here, but I found that as a really big
win for me.
So rdmd is available.
The LDC compilers, you also have this available as well with L, dmd2.
I haven't checked the GDC one actually.
So that was really cool.
So, you know, generally speaking to, you know, my effort because I was running
somebody who does little scripts was, you know, if you use a compiled language,
generally, gotta be careful with talking about performance.
You get better performance than an interpreted scripting language.
So again, a big win for me and my projects.
But there is still more to this performance story beyond just, you know,
switching to a compiled language here.
Because I started stumbling upon other really cool things in the deprogramming
language, the community pointed me to.
I started doing this in my scripts here.
So you'll see here highlighted, let me draw your attention towards the top.
Dot parallel here.
So I just kind of stick that on the end of some collection or some array.
And basically what I get is the equivalent of, for those of you who've done
OpenMP, a parallel-based for loop here, right?
We're able to launch multiple threads here.
That's a small change that you can make, right?
If you don't have any dependencies on the data in between, you still have to
think about it, certainly to make sure you get correct code.
But imagine just going through all of your range-based for loops and doing dot
parallel.
And if you're doing separate tasks, getting a performance boost, right?
Use your CPU.
You paid a lot of money for it, so put it to work.
So again, quality of life feature there.
Now does it make things faster?
Again, you have to profile.
You always got to check these things out.
So, you know, maybe a better use case, another open source project from a
D conference, just a standard, you know, Hello World Ray Tracer project where I
used standard parallelism.
And again, if you're looking per pixel or doing something graphically, right,
you have a lot of pixels, however wide your resolution is, a thousand pixels,
but, you know, a thousand something of that nature.
You can try dot parallel on it and see if it speeds things up.
And of course, my performance wizards and the spiniers.
You're launching too many threads or what's going on, you know.
So, you know, does it make things faster?
I'll get to that in one slide here.
Because I also see something interesting that I've touched on but haven't explained.
What's going on in this for each loop?
For each Y and for each X, okay, those must be like the pixels going across and up and
down.
Okay, so there's a lot of them.
But this next part's kind of interesting.
Okay, I've got a camera dot get screen height dot iota, which is like a range,
and then that dot parallel.
Well, what this is, is an example of that uniform function call syntax.
This idea that we can sort of chain functions together with a dot.
Again, maybe you've seen this about programming languages.
Maybe you've implemented design patterns that allow you to do this.
But it's a really nice quality of life feature if you just sort of compare the camera dot
get screen height dot iota dot parallel versus, you know, trying to figure out how do I nest
these things.
Parallel, okay, iota, and then you're counting your parentheses or, you know, you're hoping
them or whatever counts them correctly for you.
Again, just a little quality of life thing, more readable code, and you can actually think
and sometimes see like, oh yeah, I see that is just a range there.
Maybe I can paralyze it.
Maybe there is some data independent thing there.
So anyways, that's just, you know, following up on that.
And then as a little aside, and you can look a little bit more, there is a built-in profiler
in the D compiler for seeing how many times a function executes, how much time you spend
in it, and there's also a memory profiler so you can see how many garbage collections
you're doing if you're using the garbage collector.
Okay, so built into the compiler, you don't have to search for them.
You know, I do use other tools like perf and choose your favorite tools, but nice that
it's there, okay?
It's an easy tool that you could build into a continuous integration system or whatever.
Okay, so, you know, speaking of some graphics projects, again, that's sort of one of my
passions, so, and it turns out that D is a great language for building graphics projects.
So, you know, the must-need-it, you know, pretty picture slide, and there's actually games
and physics, you know, if you click into this.
The cool D language project, Daegon, here is a game engine, so, you know, something sufficiently
complex.
Why do we care about this, though?
Other than it's, you know, pretty in a slideshow.
Very, very beautiful.
Lots of hard work there.
But again, just to see the substantial project by engine and graphics developers, you can
see how it's laid out, how different core systems are laid out.
Again, might be interesting for you to, again, think about if you're going to use D for
building games, how you organize different components and game objects and these types
of things.
And you can kind of look through the directory structure.
D uses a sort of directory structure for packages like Java or other languages, and
that's kind of interesting.
And there's also just a fun comparison to C++ here if you want to see the video.
It's not really to say anything.
Both these applications are very GPU bound, so that's sort of the point, right?
Use the language you want, and if you're GPU bound, that's all on the GPU anyway, so,
you know, you can think about those tradeoffs.
So there's one game engine.
Another one, Dash, this is a cool, I think it started off as a student project, and then
I gained some steam with several folks.
So there's a little game they made.
Why do you care about this?
Well, you know, I spent just a few minutes looking at the code to see how things were
structured.
And very interestingly, they were using this idea of mixins in their code.
How many folks, just as a survey, have heard of a mixin by hand?
Okay, we've got about 40% or so around there.
But that's the idea that you're literally just taking in a string and pasting in your
code, and it should be like valid decode that gets compiled.
Sounds trivial, sounds like, kind of, why would you do this?
But it makes sense in use cases if you've got graphics code, if you can just import
or paste in some shader code and do a mixin.
Or maybe you can use other compiler or compile time techniques to sort of build out a string
at compile time and then generate code.
It's a very simple idea that you can compose and generate some really cool graphics things.
I think it tends to work well in this use case that the game showed.
Another later project here, Hypreem Engine.
So they built, you know, some nice stuff.
Why do you care about it?
Why should we look at it?
Well, Hypreem is very active in the community, so a good person to know for one.
But a really interesting example of just seeing how to support multiple platforms.
So again, Hypreem can build a D project on PlayStation Vita, Xbox, Mac, iOS, Android,
et cetera.
Just to see that that's accessible, I think that's a project worth studying and to see,
you know, how did they get there?
Okay.
All right.
So there's lots of other graphics resources.
Mike Parker, who's a member of the community, has done a great job with common libraries
and graphics stuff, sort of an FYI.
We're talking about open source today, so I'm going to sort of ignore the commercial game
projects done in D, but there's a few interesting talks, again, if that's your sort of domain.
And, okay, so talking about a few of the other D language things of interest, the paradigms,
okay?
Because again, I said when I started using D, I started doing things more functionally.
I started thinking more about concurrency.
I started thinking about object-oriented programming, I think in the right way.
At least, you know, how message passing is supposed to be one of those pillars of object-oriented
programming that kind of gets forgotten sometimes.
At least that's what I think of with object-oriented programming.
But anyways, just a couple of examples.
You can take a peek at these again after the talk, but I've got the range-based loop here,
and then I've got the sort of the mantra of no raw loops.
Get rid of those raw loops and just use functions like filter or, you know, these types of components here.
So again, very nice, often easy to substitute, often you find instances where you can just do a dot-parallel
much more easily.
And on the right here is just a classic.
You've got an interface, and you want to create a type of dog, a husky golden retriever, you know,
like your favorite dog, Belgian Shepherd, et cetera.
Okay, and then I can't leave D without giving a hollow world of metaprogramming,
because that's really, again, one of the strengths here, right?
We talked about stuff that you could do at compile time.
So just a sort of simple function here.
It's called print data.
So I'll draw your attention towards line 38.
T is the template parameter, so there's no angular brackets.
You just put the template parameters right after here.
So T, whatever the data type would be, and I've got another T for whatever that type is, and then the struct.
Okay, what is the struct and why do we care about it?
Well, we care about this struct only if it has members, right, attributes called memory and elements.
Okay, so memory might be a chunk of the, you know, I don't know, some attribute of the elements is maybe, again, an array of the data.
So what's sort of interesting is, one, you can think about this as a sort of template constraint, or a concept,
again, depending on what language you're coming from, that has to be adhered to.
So I can only use this templated function on structs to print their data if it has memory and elements.
Well, I think that's kind of a nice constraint to think about or to have that ability to do it.
So that's kind of interesting here.
If we have time at the end, I'll flash some of the examples that I'm going to put in the GitHub repository for other introspection things you can do.
You've got a traits library, so you can see, you know, what member functions you have.
Is this thing a unit test? Does it have some attribute on it, like no GC or whatever?
A question?
And the question was, is there static if? There is static if. There's static for each.
My question is why you use static.
Why it's not static? Here, it's, I guess I could make this static. I don't know if it's implicit actually here.
I need to think if it is or not.
Yeah, I guess, yeah, we don't need it because technically we wouldn't generate this template if it wasn't valid, since that's happening at compile time.
Okay. So, you know, here's, you know, leading us towards the end.
So, I know, I've gone through this. I've tried not to make it a sales pitch just to show you things that I'm excited about.
But if you're not ready to try, D, there's still yet other interesting things in the compiler.
There's something called better C, which is a subset of the D language.
And basically what this does is it gets rid of or sort of removes a lot of the language run time.
So, this is if you want to do some more like bare metal programming, for instance, and you don't want to carry the standard library phobos,
or you don't need some of these other features.
You get most of the quality of life things, like the bounds checking with arrays, you get slices for working with them, you know, delegates,
land as all those nice things, all the compile time execution, but you can sort of just use it as a better C language.
Some of the stuff you're starting to see in C23, for instance.
And there's a really nice talk introducing that on kernels and how they're using better C for kernel development.
So, again, getting into a little level stuff here.
So, as far as learning more about the language, again, great tour on the website.
The good news is, you know, anybody who's written a book on the D programming language, and there's seven or eight, I think,
they're all good books, right? They're all written by enthusiasts, reviewed by the community.
These are the first two I'm going to recommend that folks who are beginners take a look at.
They're more, you know, for someone who's an audience who knows how to program, and we'll get you started here.
Forums and Discord, otherwise, are very active as well.
YouTube, that's me.
And then teaching the D language.
So, you can hear it from my perspective again, but even better if you hear it from the students, right?
They're unbiased thoughts on what the value was, if it was useful for them.
And the last sort of resources as we're kind of wrapping up here to talk about, again, from Andre, he wrote this really nice piece here called The Case for D.
This was in 2009. I think a lot of it still holds in a way, but, you know, basically, he summarizes it as a high-level systems language where it can be productive and enjoy coding.
That's what I found. You know, maybe you'll find that too.
Okay, again, that's up to you to decide.
I hope I just shared some cool stuff for you to get excited about otherwise.
So, again, what do we care maybe as an open-source developer?
You know, you've got a readable, writeable, performance language that hopefully gives you a lot of quality of life features like fast iteration time.
You know, I think there's a competitive advantage here with any project.
I found it with my students. Again, that's something you'll have to test, but that's what I found.
My students get further using D than other programming languages.
And there's three compilers available. You don't have to worry about it disappearing or, you know, other stuff, you know, going on here.
All right, what's next for me?
Well, I talked a whole lot about graphics. That's my passion. That's what I've worked in.
But I'm now working on learning a web framework called Vibe, which is super cool.
If you're more on the website, there's a great book about it to get you started on building, you know, scalable and performance web applications.
Alrighty, so we learned a bunch of things. Here's sort of a summary slide on some of our takeaways.
Again, I'm going to leave that wall of text for you because I want you to leave excited and not tired from reading.
I just want to go ahead and close off by thanking you.
I'm going to be around so you can ask me any questions now or after as well.
Thank you.
A question?
What you will say, why Rust and why not Rust and why D?
That's a good question. I don't want to pit languages against each other, so it's why Rust or why D?
What I would say, because that's a hot question I get asked a lot, D's code is very plastic, the plasticity is high.
Meaning I can mold it and change it, which I very much like.
In a way that, again, I'm not as much a Rust expert. I've used it a little bit, but D's plasticity is very good.
It writes how I want to write the code. It's got the memory safety with the garbage collection itself.
I find it very, very productive. I find if you're going to write an application, again, I'm in games and so on where there's lots of mutable state.
D's a perfect fit for that, for writing safety and maintainable code that I can change later.
Yeah.
So the comment was coming from a C, this was sort of easier code to C and to read.
Yep, yeah. That's the other read. It's easy to get into.
Yeah.
Another question?
Testing. The UFCS looks very cool, but how do I know if it's like a function or if it's a method of the object like that I'm calling?
Because it felt, it was all the same color on your VIM script and I was like, oh no.
Yeah, when you're doing the dot, so a few nice things that D language does when you're working with pointers in classes one, you know, if you're coming from C or C++, there's no arrow.
So, you know, you don't have to worry about that. Everything's a dot.
But then the idea of, is it a variable that I did a dot or the function call?
Usually function calls are not required if they don't have any parameters, you can leave them empty.
I usually just put the parentheses after.
Otherwise, this is for things like language server protocol and your text editor make easy enough.
It's not usually a problem.
Yeah.
Alrighty, thank you.