Hacker News Reader

Comment by jordigh | Hacker News Reader

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

View on HN

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

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.

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

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.

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

Those come with the whole compiler at runtime.

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

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.

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.

How is it any different from, say, a makefile?

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

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.

Perl source filters

I remember a study of production Python servers that showed that past an "initialization period" the types of objects in variables settled down and essentially became static. It seems to me that this is a very common across many languages, and that this pattern could be exploited in a number of ways. (Compiling "dynamic" languages in the above case.)

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.

So then what if the language didn't have global state, or only had immutable global state?

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

I thought there was a DIP for this, but cannot seem to find it now.

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

Can you going into some details about this? Like proofs?

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)

By default, D has no safeguards to prevent you from doing memory-unsafe things, and afaik no compile-time checks short of marking your main method as @safe. However, because the language is by default memory managed, it is fairly easy to stick to safe code without this by avoiding pointer/cast voodoo.

Fortunately with array bounds checks and default initialized variables, memory corruptions aren't very common in D.

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.

From long, long ago https://news.ycombinator.com/item?id=6940624

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());
    }

'delete' is in the process of being deprecated: https://dlang.org/deprecate.html#delete

It's close, and we're working to close the remaining gaps.

Probably the biggest memory safety issue is buffer overflows, and D does a good job stopping that (array overflow checking).

Reply on news.ycombinator.com