Item — HN Reader

Not really sure why the original HN poster left "D" from its title, is there any conspiracy going on to silence D :-)

Actually unlike C++ and Rust you can have a lean D and most probably it can perform as good as Zig if not better. D has excellent CTFE support similar to Zig and D has no macro as well. If you want extra memory safety with ownership support D has that feature covered.

1 comments

> unlike C++ and Rust you can have a lean D and most probably it can perform as good as Zig if not better

I doubt this is really meaningful. The performance-ceiling on all four languages is presumably very high, as they all allow you to write hand-optimised low-level code if you want to.

What it is probably not obvious to most people is that D has supports for D as better C, so it can have seamless interaction with C library and vice versa [1]. With betterC, D supports for C interfacing and integration is second to none. Heck, you can even compile the D compiler as a library if you fancy a built-in compiler for your C and D program. This seamless integration capability can be very productive where most of the high performance libraries are written in C.

[1]https://dlang.org/blog/2017/08/23/d-as-a-better-c/

[2]https://dlang.org/blog/2017/08/01/a-dub-case-study-compiling...

Zig has similar good integration with C. The Zig compiler is also a C compiler (calls into Clang), C headers can be imported directly from Zig code and used without writing any bindings, and you can also autogenerate C headers for Zig code so that it can be used directly from C (although this is currently broken).

Pretty much, so you could as well use the one you find most productive. If productivity is not there, fast programs don't materialize.

You could go for productivity, but that's not the only dimension. You could emphasise safety: C++ has no equivalent to Rust's safe subset. I believe D has a safe subset too, but I don't think Zig does. You could emphasise portability: C++ seems like the clear winner in terms of having the most supported platforms.

Microsoft and Google are trying to retrofit a safe subset into C++, via the Core Guidelines and lifetimes, enforced via static analysers.

Since C++ is more relevant to what I do, naturally I keep validating how good they fair and so far not good.

Lifetimes checker for example, is only able to deal with basic workflows and when it complains the error messages aren't that good, leaving you wonder why the analyser considered it an incorrect lifetime.

Main reason being, if the call sites aren't annotated, it can only guess the lifetime use, and mostly it gets it wrong.

No doubt if they keep throwing money at it, they might eventually solve it, however this is already a three year effort and this is the best so far.

It's also possible to formally verify C++, [0][1] but this isn't commonly done. I imagine it's very labour intensive.

[0] https://www.eschertech.com/products/ecv.php

[1] https://trust-in-soft.com/