11 ms·

Ruminations on D: An Interview with Walter Bright

156 points by Halienja 10y ago

jordigh 10y ago
We nailed it with arrays (Jan Knepper’s idea), the basic template design, compile-time function execution (CTFE) One of my favourite things about D is that it has a full compile-time D interpreter. You can do "template metaprogramming", so to speak, in the same language as D itself (it's probably a bit more fair to compare it to how lisp macros are "compile-time"). It's a bit sad that Rust is getting all of the attention in the spotlight, because D is a great, modern, safe language. If you've only heard about D 15 years ago and never tried it again, give it another look. The current D is really a new language, which was briefly called "D2" for a while. Now, if Symantec could just fix the stupid licence of the reference compiler... https://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dlang.org?page=1 https://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dl...
- gmfawcett 10y ago
  I agree! But the compile-time interpreter isn't really "full". For example, you can't do arbitrary I/O in a compile-time expression (by design). Non-portable casts and inline ASM are other exceptions. See [1] for the full story. [1]: https://dlang.org/spec/function.html#interpretation https://dlang.org/spec/function.html#interpretation
  - Shoop 10y ago
    If inline asm or non-portable casts were allowed, D programs would compile inconsistently on different architectures. Compile time IO doesn't make much sense either. Not all limitations are shortcomings.
    - steveklabnik 10y ago
      > Compile time IO doesn't make much sense either. While I agree with D's decision here, there are other languages which do allow anything at compile time. See Jai, for example.
      - wtetzner 10y ago
        And Common Lisp, and Scheme, and Elixir, and Clojure, and I'm sure I'm missing a bunch :)
        p0nce 10y ago
        Those come with the whole compiler at runtime.
        lomnakkus 10y ago
        Even... Haskell! Dundundun! (I'm referring to Template Haskell.) As it turns out (IME) referencing arbitrary data (such as a database schema queried from a 'live' database) is actually of quite limited value. Where I actually agree that it makes sense is the 'read-a-checked-in-file-and-generate-code-at-compile-time-from-that'. Otherwise, you're mostly just looking at a lot of pain compared to just generating code (that you might check in).
    - Zardoz84 10y ago
      Compile time read have sense. For example, reading a XML to build a GUI on complete time instead on runtime (I see you GTK builder). Actually you can do this on CTFE on D, doing an import of a file and dumping it to an enum. The only big pitfall of this, is that enforces to read the whole file by the compiler.
      - Shoop 10y ago
        I withdraw my claim that compile time IO doesn't make any sense, but it is something I would be worried about. I wouldn't want the executable my build process produces to be changed by what files are laying around on the disk. Mixing in all of the state in the file system with something you want to be mostly stateless (your build process) seems like a dangerous idea to me.
        dansze 10y ago
        The compiler already depends on the state of the file system though, notably because it depends on the source code. In the above case, the xml is essentially just another source file that happens to not be in the same language. An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.
        duaneb 10y ago
        How is it any different from, say, a makefile?
      - p0nce 10y ago
        > reading a XML to build a GUI on complete time instead on runtime It can be done with: void[] ctData = import("file.xml"); For example, this feature is used in vibe.d to compile an HTML template language into more optimized code.
      - stcredzero 10y ago
        Compile time read have sense. Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)
- lucian1900 10y ago
  > D is a great, modern, safe language It's very nice, but it isn't memory safe.
  - posterboy 10y ago
    I wonder, could a portable ownership model be implemented with the templates?
    - steveklabnik 10y ago
      I thought there was a DIP for this, but cannot seem to find it now.
    - pcwalton 10y ago
      Not soundly, no. The borrow check requires flow-sensitive analysis. The lifetime typechecker requires subtyping-aware extensions to Hindley-Milner.
      - nialv7 10y ago
        Can you going into some details about this? Like proofs?
  - Shoop 10y ago
    When is D not memory safe?
    - steveklabnik 10y ago
      It has been years since I have actively programed in D, so take this with a grain of salt, but my understanding is that D only guarantees memory safety in its @safe subset. See here: https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html Context: safe Rust is also a subset of unsafe Rust. But when people mention a language without qualifiers, they mean whatever the default is. D (appears) to default to a non-memory safe language, and Rust defaults to a memory-safe one. I believe this is what OP meant. (this also ignores the relative feature sets of the various sub/super-sets)
- pcwalton 10y ago
  > It's a bit sad that Rust is getting all of the attention in the spotlight This isn't a zero-sum game! D is a fine language.
  - jordigh 10y ago
    There is a limited resource here, which is programmers' time and attention. If everyone is scrambling to Rust, they will probably not give D as much attention. Without attention, D will probably not have a healthy collection of 3rd party libraries and tools.
    - lifthrasiir 10y ago
      I think D have been already given tons of attention, especially in its early years (just like other newer languages). That early-day reception defines the acceptance in, say, next decade---at which Rust has been relatively excelled than D, IMHO.
- justin66 10y ago
  To someone with only a passing interest, but a real interest nonetheless, D's position in the spotlight is a lot more comfortable than what's going on with rust. After a while, the way every thread about c, c++, systems programming, or operating systems draws the same predictable rust comments feels like being assaulted by a lunatic wielding a cheese grater.
  - santaclaus 10y ago
    I've seen this phenomenon called 'Rustwins law' as it bears striking similarities to Godwin's law in its inevitability.
    - stcredzero 10y ago
      If the law suggests that Rust wins, I'm sure the Rust community will not strenuously object.
      - notriddle 10y ago
        If it's going to match Godwin's Law, then whoever mentions Rust automatically loses the argument...
        jordigh 10y ago
        Godwin's law isn't about losing the argument. It's just an observation that national socialism is going to be mentioned in the limit as the conversation grows without end.
jbb555 10y ago
I took a look again at D this last couple of weeks and it was a way better language than I remembered. It seems like a very solid language. You can write low level C like code if you really want to, but it defaults to safer, higher level code without losing much efficiency. I'm going to try it out with some bigger projects. I have some issues. Windows support seems a little flakey but it's ertainly usable (the default dmd compiler works very well on windows but the code it makes isn't the best it could be, and ldc makes much higher quality code, but isn't quite stable on windows. (Although it's certainly looking good enough to use). I think it's well worth a look. I like it a great deal more than Rust
tree_of_item 10y ago
I like a lot of things about D, but I don't like the fact that it seems stuck in the OOP fad from 15 or so years ago. Go and Rust have both abandoned this whole idea of making "classes" in favor of constructs like structs, enums, traits and interfaces. I wish D had gone this route as well, but other than that it seems like a nice language.
- FraaJad 10y ago
  Eh.. I wrote a 1000 line linux "system" application in D. Didn't use a single class. All enums and structs pretty much like you would approach it like good "C" programmer while still using all of D's goodness.
  - tree_of_item 10y ago
    D enums are not the good kind of enums (i.e. sum types, like in Rust), though. Instead they have some silly implementation of sum types using classes in std.variant.
    - Profan 10y ago
      It's not a class, it's a struct (as a value type), it's fine if you disagree with the idea of OOP, but don't come in with an incorrect assumption of how the language is actually used in the wild. But sure, I would agree that having a natively implemented variant type would be better, even if this one can serve many of the same purposes. Class = reference type, supports polymorphism, inheritance Struct = value type, does not support polymorphism, inheritance The variant type based on a struct is implemented through the language's metaprogramming facilities.
    - zem 10y ago
      this is my primary "complaint" about D; i strongly prefer languages with algebraic datatypes and pattern matching built in. other than that it does indeed look like a beautiful language. ironically, i haven't really used D for the same reason i haven't really used rust - i've yet to have a project for which ocaml wasn't a better choice. (i know both D and rust address things ocaml doesn't, but they aren't the things i tend to need for my personal projects.)
grundprinzip 10y ago
What I found interesting is that the two high profile projects mentioned in the post written in D are no longer maintained, which is kind of weird.
- webreac 10y ago
  Maybe they are completely finished and bug free ;-)
- bedros 10y ago
  I love D language, and all what it needs is a high profile production project that uses D. and then more people will look into considering using D in their production environment.
  - vram22 10y ago
    See what Walter says in the interview about that.
Keyframe 10y ago
You were 42 when you started working on D and I guess it is the first language you designed? Talk about why you started working on it so late... What kind of question is that? Anders Hejlsberg was what, 39 when he started working on C# and 52 with Typescript? It's the same as with screenplays. You start writing when you have experience.
- jsmthrowaway 10y ago
  It struck me as odd, too, but then I realized I didn't know the cultural background of interviewer or interviewee and maybe it was a welcome, completely normal question. It's useful to keep your own dispositions in mind when analyzing someone else's conversation.
  - Keyframe 10y ago
    Not valid, since question comes preloaded with an assumption language designers start a lot earlier ("so late").
    - jsmthrowaway 10y ago
      That's a fair point. I hadn't looked at it that way.
    - abiox 10y ago
      maybe. perhaps they're referring to his long career and curious about what motivated him at that point to pursue the project versus times previous.
      - Keyframe 10y ago
        When you put it that way, could be that as well. Bad interviewer is bad, I guess.
- fdej 10y ago
  I think serial PL designer Wouter van Oortmerssen started creating languages in his teens...
vram22 10y ago
This video of a panel discussion at a conf was interesting to me: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... Key team members or inventors of those languages, speak.
- steveklabnik 10y ago
  Standard disclaimer: It's been a while since I watched that video, but this was before Rust 1.0, and so all statements about Rust in it should be taken with a grain of salt. Lots changed.
  - SamReidHughes 10y ago
    Not in any way that was pertinent.
    - steveklabnik 10y ago
      Great, I will stop worrying about that, then. I'd actually been meaning to re-watch this specifically to double check for a while.
  - vram22 10y ago
    Good point, and I suppose some of the same may be the case about the other languages as well. My own disclaimer, though it shouldn't really be needed: I only put the link out of interest. No points to make.
    - steveklabnik 10y ago
      Definitely didn't assume you were. Because there was so much interest in Rust pre-1.0, there's a lot of outdated material out there, and so it can confuse people. https://github.com/rust-lang/rust/issues/14954 https://github.com/rust-lang/rust/issues/14954 specifically was a huuuuge headache for a long time. This is slowly changing, of course, the farther we get away from 1.0. I still worry about it, though.
zokier 10y ago
Hows the Dlang GC these days? A year ago andralex stated that he was going to work on it[1], but I haven't heard of that since. [1] https://www.reddit.com/r/programming/comments/2g03af/ds_garbage_collector_problem/ckent8c https://www.reddit.com/r/programming/comments/2g03af/ds_garb...
- bachmeier 10y ago
  Someone was supposed to be working on the GC for a GSoC project, but I haven't heard any recent updates. http://forum.dlang.org/post/jcfwcdvvfytdkjrpdeld@forum.dlang.org http://forum.dlang.org/post/jcfwcdvvfytdkjrpdeld@forum.dlang...
  - Profan 10y ago
    They're working on getting precise GC in, he's been working on it quietly with a mentor and another two GC specialists in the D community for a while :) https://github.com/dlang/druntime/pull/1603 https://github.com/dlang/druntime/pull/1603
stirner 10y ago
> I don’t worry too much about that. I spend my efforts making D the best language possible, and let the metrics take care of themselves. It’s like being a CEO; he shouldn’t be sweating the stock price, he should be working on making money for the company, then the stock price will take care of itself. I wish this mindset was more prevalent in open source. I find that the best (most well-designed and useful) projects are those that don't concern themselves with marketing.

156 points by Halienja 10y ago

We nailed it with arrays (Jan Knepper’s idea), the basic template design, compile-time function execution (CTFE) One of my favourite things about D is that it has a full compile-time D interpreter. You can do "template metaprogramming", so to speak, in the same language as D itself (it's probably a bit more fair to compare it to how lisp macros are "compile-time"). It's a bit sad that Rust is getting all of the attention in the spotlight, because D is a great, modern, safe language. If you've only heard about D 15 years ago and never tried it again, give it another look. The current D is really a new language, which was briefly called "D2" for a while. Now, if Symantec could just fix the stupid licence of the reference compiler... https://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dlang.org?page=1 https://forum.dlang.org/thread/lodjbuvdhimrvrdngldy@forum.dl...

gmfawcett 10y ago
I agree! But the compile-time interpreter isn't really "full". For example, you can't do arbitrary I/O in a compile-time expression (by design). Non-portable casts and inline ASM are other exceptions. See [1] for the full story. [1]: https://dlang.org/spec/function.html#interpretation https://dlang.org/spec/function.html#interpretation
- Shoop 10y ago
  If inline asm or non-portable casts were allowed, D programs would compile inconsistently on different architectures. Compile time IO doesn't make much sense either. Not all limitations are shortcomings.
  - steveklabnik 10y ago
    > Compile time IO doesn't make much sense either. While I agree with D's decision here, there are other languages which do allow anything at compile time. See Jai, for example.
    - wtetzner 10y ago
      And Common Lisp, and Scheme, and Elixir, and Clojure, and I'm sure I'm missing a bunch :)
      - p0nce 10y ago
        Those come with the whole compiler at runtime.
      - lomnakkus 10y ago
        Even... Haskell! Dundundun! (I'm referring to Template Haskell.) As it turns out (IME) referencing arbitrary data (such as a database schema queried from a 'live' database) is actually of quite limited value. Where I actually agree that it makes sense is the 'read-a-checked-in-file-and-generate-code-at-compile-time-from-that'. Otherwise, you're mostly just looking at a lot of pain compared to just generating code (that you might check in).
  - Zardoz84 10y ago
    Compile time read have sense. For example, reading a XML to build a GUI on complete time instead on runtime (I see you GTK builder). Actually you can do this on CTFE on D, doing an import of a file and dumping it to an enum. The only big pitfall of this, is that enforces to read the whole file by the compiler.
    - Shoop 10y ago
      I withdraw my claim that compile time IO doesn't make any sense, but it is something I would be worried about. I wouldn't want the executable my build process produces to be changed by what files are laying around on the disk. Mixing in all of the state in the file system with something you want to be mostly stateless (your build process) seems like a dangerous idea to me.
      - dansze 10y ago
        The compiler already depends on the state of the file system though, notably because it depends on the source code. In the above case, the xml is essentially just another source file that happens to not be in the same language. An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.
      - duaneb 10y ago
        How is it any different from, say, a makefile?
    - p0nce 10y ago
      > reading a XML to build a GUI on complete time instead on runtime It can be done with: void[] ctData = import("file.xml"); For example, this feature is used in vibe.d to compile an HTML template language into more optimized code.
    - stcredzero 10y ago
      Compile time read have sense. Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)
lucian1900 10y ago
> D is a great, modern, safe language It's very nice, but it isn't memory safe.
- posterboy 10y ago
  I wonder, could a portable ownership model be implemented with the templates?
  - steveklabnik 10y ago
    I thought there was a DIP for this, but cannot seem to find it now.
  - pcwalton 10y ago
    Not soundly, no. The borrow check requires flow-sensitive analysis. The lifetime typechecker requires subtyping-aware extensions to Hindley-Milner.
    - nialv7 10y ago
      Can you going into some details about this? Like proofs?
- Shoop 10y ago
  When is D not memory safe?
  - steveklabnik 10y ago
    It has been years since I have actively programed in D, so take this with a grain of salt, but my understanding is that D only guarantees memory safety in its @safe subset. See here: https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html Context: safe Rust is also a subset of unsafe Rust. But when people mention a language without qualifiers, they mean whatever the default is. D (appears) to default to a non-memory safe language, and Rust defaults to a memory-safe one. I believe this is what OP meant. (this also ignores the relative feature sets of the various sub/super-sets)
pcwalton 10y ago
> It's a bit sad that Rust is getting all of the attention in the spotlight This isn't a zero-sum game! D is a fine language.
- jordigh 10y ago
  There is a limited resource here, which is programmers' time and attention. If everyone is scrambling to Rust, they will probably not give D as much attention. Without attention, D will probably not have a healthy collection of 3rd party libraries and tools.
  - lifthrasiir 10y ago
    I think D have been already given tons of attention, especially in its early years (just like other newer languages). That early-day reception defines the acceptance in, say, next decade---at which Rust has been relatively excelled than D, IMHO.
justin66 10y ago
To someone with only a passing interest, but a real interest nonetheless, D's position in the spotlight is a lot more comfortable than what's going on with rust. After a while, the way every thread about c, c++, systems programming, or operating systems draws the same predictable rust comments feels like being assaulted by a lunatic wielding a cheese grater.
- santaclaus 10y ago
  I've seen this phenomenon called 'Rustwins law' as it bears striking similarities to Godwin's law in its inevitability.
  - stcredzero 10y ago
    If the law suggests that Rust wins, I'm sure the Rust community will not strenuously object.
    - notriddle 10y ago
      If it's going to match Godwin's Law, then whoever mentions Rust automatically loses the argument...
      - jordigh 10y ago
        Godwin's law isn't about losing the argument. It's just an observation that national socialism is going to be mentioned in the limit as the conversation grows without end.

jbb555 10y ago

I took a look again at D this last couple of weeks and it was a way better language than I remembered. It seems like a very solid language. You can write low level C like code if you really want to, but it defaults to safer, higher level code without losing much efficiency. I'm going to try it out with some bigger projects. I have some issues. Windows support seems a little flakey but it's ertainly usable (the default dmd compiler works very well on windows but the code it makes isn't the best it could be, and ldc makes much higher quality code, but isn't quite stable on windows. (Although it's certainly looking good enough to use). I think it's well worth a look. I like it a great deal more than Rust

tree_of_item 10y ago

I like a lot of things about D, but I don't like the fact that it seems stuck in the OOP fad from 15 or so years ago. Go and Rust have both abandoned this whole idea of making "classes" in favor of constructs like structs, enums, traits and interfaces. I wish D had gone this route as well, but other than that it seems like a nice language.

FraaJad 10y ago
Eh.. I wrote a 1000 line linux "system" application in D. Didn't use a single class. All enums and structs pretty much like you would approach it like good "C" programmer while still using all of D's goodness.
- tree_of_item 10y ago
  D enums are not the good kind of enums (i.e. sum types, like in Rust), though. Instead they have some silly implementation of sum types using classes in std.variant.
  - Profan 10y ago
    It's not a class, it's a struct (as a value type), it's fine if you disagree with the idea of OOP, but don't come in with an incorrect assumption of how the language is actually used in the wild. But sure, I would agree that having a natively implemented variant type would be better, even if this one can serve many of the same purposes. Class = reference type, supports polymorphism, inheritance Struct = value type, does not support polymorphism, inheritance The variant type based on a struct is implemented through the language's metaprogramming facilities.
  - zem 10y ago
    this is my primary "complaint" about D; i strongly prefer languages with algebraic datatypes and pattern matching built in. other than that it does indeed look like a beautiful language. ironically, i haven't really used D for the same reason i haven't really used rust - i've yet to have a project for which ocaml wasn't a better choice. (i know both D and rust address things ocaml doesn't, but they aren't the things i tend to need for my personal projects.)

grundprinzip 10y ago

What I found interesting is that the two high profile projects mentioned in the post written in D are no longer maintained, which is kind of weird.

webreac 10y ago
Maybe they are completely finished and bug free ;-)
bedros 10y ago
I love D language, and all what it needs is a high profile production project that uses D. and then more people will look into considering using D in their production environment.
- vram22 10y ago
  See what Walter says in the interview about that.

Keyframe 10y ago

You were 42 when you started working on D and I guess it is the first language you designed? Talk about why you started working on it so late... What kind of question is that? Anders Hejlsberg was what, 39 when he started working on C# and 52 with Typescript? It's the same as with screenplays. You start writing when you have experience.

jsmthrowaway 10y ago
It struck me as odd, too, but then I realized I didn't know the cultural background of interviewer or interviewee and maybe it was a welcome, completely normal question. It's useful to keep your own dispositions in mind when analyzing someone else's conversation.
- Keyframe 10y ago
  Not valid, since question comes preloaded with an assumption language designers start a lot earlier ("so late").
  - jsmthrowaway 10y ago
    That's a fair point. I hadn't looked at it that way.
  - abiox 10y ago
    maybe. perhaps they're referring to his long career and curious about what motivated him at that point to pursue the project versus times previous.
    - Keyframe 10y ago
      When you put it that way, could be that as well. Bad interviewer is bad, I guess.
fdej 10y ago
I think serial PL designer Wouter van Oortmerssen started creating languages in his teens...

vram22 10y ago

This video of a panel discussion at a conf was interesting to me: Video: C++, Rust, D and Go: Panel at LangNext '14: http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-panel-at-langnext.html http://jugad2.blogspot.in/2016/08/video-c-rust-d-and-go-pane... Key team members or inventors of those languages, speak.

steveklabnik 10y ago
Standard disclaimer: It's been a while since I watched that video, but this was before Rust 1.0, and so all statements about Rust in it should be taken with a grain of salt. Lots changed.
- SamReidHughes 10y ago
  Not in any way that was pertinent.
  - steveklabnik 10y ago
    Great, I will stop worrying about that, then. I'd actually been meaning to re-watch this specifically to double check for a while.
- vram22 10y ago
  Good point, and I suppose some of the same may be the case about the other languages as well. My own disclaimer, though it shouldn't really be needed: I only put the link out of interest. No points to make.
  - steveklabnik 10y ago
    Definitely didn't assume you were. Because there was so much interest in Rust pre-1.0, there's a lot of outdated material out there, and so it can confuse people. https://github.com/rust-lang/rust/issues/14954 https://github.com/rust-lang/rust/issues/14954 specifically was a huuuuge headache for a long time. This is slowly changing, of course, the farther we get away from 1.0. I still worry about it, though.

zokier 10y ago

Hows the Dlang GC these days? A year ago andralex stated that he was going to work on it[1], but I haven't heard of that since. [1] https://www.reddit.com/r/programming/comments/2g03af/ds_garbage_collector_problem/ckent8c https://www.reddit.com/r/programming/comments/2g03af/ds_garb...

bachmeier 10y ago
Someone was supposed to be working on the GC for a GSoC project, but I haven't heard any recent updates. http://forum.dlang.org/post/jcfwcdvvfytdkjrpdeld@forum.dlang.org http://forum.dlang.org/post/jcfwcdvvfytdkjrpdeld@forum.dlang...
- Profan 10y ago
  They're working on getting precise GC in, he's been working on it quietly with a mentor and another two GC specialists in the D community for a while :) https://github.com/dlang/druntime/pull/1603 https://github.com/dlang/druntime/pull/1603

stirner 10y ago

> I don’t worry too much about that. I spend my efforts making D the best language possible, and let the metrics take care of themselves. It’s like being a CEO; he shouldn’t be sweating the stock price, he should be working on making money for the company, then the stock price will take care of itself. I wish this mindset was more prevalent in open source. I find that the best (most well-designed and useful) projects are those that don't concern themselves with marketing.