> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust.

It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.

D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.

The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.

How is D's memory safety without the GC? How does it guarantee you don't use-after-free, de-ref nulls, buffer overflow, etc?

Great question! The answer is a bit more than a simple reply can do, so:

Pointers Gone Wild: Memory Safety and D http://dconf.org/2017/talks/bright.html

It seems like use-after-free is still a potential issue, even with those guard rails. Rust deals with those through named lifetimes --would those ideas be useful in D as well?

Walter, you're always so responsive in these threads! Cheers.

This is being worked on, but there is already memory safety checks implemented in the compiler (That one can use now) "-dip1000"

Is the D standard library GC-free?

If not, then I would posit that it's not correct to say that it matches my definition.

I will argue that Go is more of a better C than a better C++

Go is more a better Python. Even simpler syntax. Types and compiles to native (as they are all the fashion now).

Rust is the best bet we have at a better C (and a better low-level C++).

High level C++ competes with D and Go. Rust is a little too specifically targetted at the low level "systems" programming.

I don't think a "better Python" can be statically typed - dynamic typing, and all the associated runtime tricks that you can do with it, is kinda part of what makes Python distinctive (whether for good or bad, opinions differ there).

Go has this "interface" thing which lets you do duck-typing, and it's checked at run-time, as the types in Python.

This is consumer-side duck typing. Python also provides producer-side duck typing - you can make any of your objects a duck dynamically, by making them behave like a duck at runtime. I'm not aware of anything similar in Go wrt interfaces.

Rust also shines when it comes to high level abstractions. This is what attracts me to the language: as in C++, it covers the super low-level stuff, but it also powerful in business logic abstractions.

Go has far more in common with Java than it does with python. Arcane APIs that are incredibly difficult to use correctly while having a very simple base language.

I found the Go APIs I have worked with far more simple and idiomatic than any Java libraries I have worked with (which is admittedly not a lot).

It is, to a degree a matter of taste, of course, but Go APIs tend to be rather simple, whereas Java libraries seem to often have FileOpenDialogStyleTemplateProcessorFactoryFactory-type interfaces.

The major problem I have with Go currently is lack of function overloading, which means you either have to convert your data around a lot or have many similar functions for different data types that do the same thing (basically), but have different names.

I think the comparison with Python is quite fitting, because both languages encourage a certain way to think about and implementing things. For Python it's called pythonic, in Go it's called idiomatic.

For my edification, could you give an example of such an API in Go?

And more of a spiritual successor than an actual one.

You probably won't be writing kernels with it.

No as Go has a GC. It's just supposed to be a fast server-side language without very complicated code. Go is mostly successful due to Google and filling a niche (fast, simple, concurrent, all thrown into a fat statically linked binary I think).

> No as Go has a GC.

So what, so do Oberon, Modula-3 and many others including D.

Yet quite a few production OSes were even written with them, e.g. Native Oberon for the Ceres Workstation at ETHZ.

I think I'd rather not have GC in my OS. Oberon was a pretty small language, so perhaps the pauses were more acceptable.

It even supported live video editing.

Pauses weren't an issue for users' productivity.

I'd have to know more details to see y that's not a problem. Vastly superior code, or just a very lightweight system.. I dunno.

What is kind of left from the documentation. There are other sources but this one is easier to refer to.

http://www.ocp.inf.ethz.ch/wiki/Documentation/Front

Video editor playing a video on the lower right corner.

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?...

> Others are "something better than C++ for most apps you'd write in C++ today".

As big C++ fan and language geek, I am pretty confident that if Java and .NET had taken the route of all other alternatives in the 90's (Oberon, Eiffel, Modula-3, Delphi,...), C and C++ would be less relevant today than they turned out to be.

This because many people make use of them, just because they are the only languages they know about compilers that produce AOT executables, with the option of static linking them.

Maybe even Longhorn would have been a success, instead of having to wait for UWP with .NET Native.

Indeed. With C# especially it is rather ironic, because the timeline of its development closely overlaps with D - I remember learning the newly released C# 1.0 as I was experimenting with those early 0.x versions of D.

I agree with your points. I do like to bring Nim up as it uses python like syntax with types and then transpiles to C. You get a fast and small native binary and can choose from 2 different GC or no GC. It has a small, but very active community.