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.dl...

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

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.

  > 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.

And Common Lisp, and Scheme, and Elixir, and Clojure, and I'm sure I'm missing a bunch :)

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.

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.

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?)

Some languages do have a "life before main", but it's not always clear that it's a good thing. I don't have a link offhand, but I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings.

D is a great, modern, safe language

It's very nice, but it isn't memory safe.

I wonder, could a portable ownership model be implemented with the templates?

Not soundly, no. The borrow check requires flow-sensitive analysis. The lifetime typechecker requires subtyping-aware extensions to Hindley-Milner.

When is D not memory safe?

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

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)

Yes, Rust picked the better default and D is too mature to change it now, unfortunately. Likewise with "pure", "const", and maybe even "nothrow" and "nogc".

However, I don't think it is such a big deal, since you can patch it quite well. Mark your main function as @safe and you are force to make everything @safe (or @trusted as a workaround). The type checker will tell you where to look next.

It is interesting that Rust functions are not pure by default. I guess (did not follow the design discussions), because purity is too limiting. D came up with the concept of "weakly pure", which is useful and strong enough. Also you need transitive const to turn a weakly pure into really pure function.

Always:

    import std.c.stdio;

    int main() {
	int x = 7;
	int* p = &x;
	 printf ("%d\n", *(p + 1));
	return 0;
    }

This compiles in D and violates memory safety.

If you prefer a documentation answer(https://dlang.org/spec/arrays.html#pointers) These are simple pointers to data, analogous to C pointers. Pointers are provided for interfacing with C and for specialized systems work. There is no length associated with it, and so there is no way for the compiler or runtime to do bounds checking, etc., on it.

Add '@safe' to main()'s declaration and it will no longer compile.

    import std.stdio;

    @safe int f() {
      int* x = new int(6);
      delete x;  // !!
      return *x; // !!!!
    }

    @safe void main() {
      writeln(f());
    }

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.

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.

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.

I've seen this phenomenon called 'Rustwins law' as it bears striking similarities to Godwin's law in its inevitability.

If the law suggests that Rust wins, I'm sure the Rust community will not strenuously object.

If it's going to match Godwin's Law, then whoever mentions Rust automatically loses the argument...

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.

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.

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.

You'll never satisfy everyone I guess. For me personally, I wish D went more the OOP route (as the Tango library did in D1 times), rather than the template/metaprogramming way it went with. Some of the error messages from D rival C++ STL template vomit.

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.

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.

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.

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.

Not valid, since question comes preloaded with an assumption language designers start a lot earlier ("so late").

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.

I think serial PL designer Wouter van Oortmerssen started creating languages in his teens...

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-pane...

Key team members or inventors of those languages, speak.

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.

Not in any way that was pertinent.

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.

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 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.

D has a similar problem. There is quite some outdated material on D1 out there. :)

Yes. There are pages that start with dlang.org/phobos/... and others that start with dlang.org/library/... I need to confirm but I think the "Phobos" ones are for the current library of D(ver)2 and "library" ones are for Tango, a different library that diverged from the standard one during the D1 days - something like that. I think I read that they have later sort of unified again, either that, or Tango is obsolete or less recommended. Maybe others who know more can comment.

Everything on dlang.org is fine. The phobos/ and library/ sections are two versions of the same content, generated from the same source files at the same time. The library/ stuff is the future, but not completely polished yet.

The obsolete stuff is dsource.org. Most of it does not compile anymore and has no maintainers. If you are looking for libraries to use, go to https://code.dlang.org/.

Phobos is the standard library. Tango is a D1 projects. Most of it has been ported and integrated into Phobos now. Some people still like the Tango XML library: https://github.com/SiegeLord/Tango-D2

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_garb...

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...