Hacker News Reader

Comment by iddan | Hacker News Reader

Sounds to me like they would be better off with Rust as they are actively avoiding GC. How are the two languages compare in this problem space?

View on HN

You can avoid GC with a non-GC standard library that they actually wrote:

https://github.com/weka-io/mecca

Here's the thing though: They wrote a new compiler and a new standard library to make the language work for them. How exactly is that good publicity for D?

D itself looked and still looks very interesting to me, as it can be very performant, without having insanely ugly syntax such as c++ or rust (inb4 rUsT iS VeRy ReADaBlE).

If D didn't have compelling advantages, they wouldn't have invested such effort.

Also, when one is really after every erg of performance, one often finds a need to work under the hood to improve it for one's special use cases.

For example, many, many, MANY C and C++ users replace malloc/free, and/or write their own custom allocator.

> D itself looked and still looks very interesting to me, as it can be […] without having insanely ugly syntax such as c++ or rust (inb4 rUsT iS VeRy ReADaBlE).

I did a quick dive into aforementioned stdlib only to stumble upon something I would rather prefer any Rust/C++ version over: https://github.com/weka-io/mecca/blob/f5dc6d9f71983ea7b852ad...

Some might want to exempt standard library from the "readable code" argument, but I'd argue that readability argument was lost the moment language designers allowed anyone to write things like `whatisthis!"whatever"({t.__ctor(args);})` (regardless of best practices that regular devs might unanimously follow). You can't just say that "A is bad 'cause it allows unreadable code" and follow that with "nobody's doing bad things in B therefore it's much better".

that's just nitpicking. I bet you can find equally ugly examples in the other 2 languages. My point is that "standard" code is infinitely more readable than either c++ or rust.

> My point is that "standard" code is infinitely more readable than either c++ or rust.

Still I'm struggling to see any code that is significantly more readable because of D's design decisions, or details on what makes D more readable than $lang (especially compared to modern C++/Rust that you seem to despise so much).

1. Template syntax. For example, a struct template in D is:

    struct S(T) { ... }

A function template is:

    T func(T)(T t) { ... }

2. No forward reference declarations required. This cuts down on a mass of unnecessary boilerplate. Even better, it allows the coding style of ordering the functions from most important to least important, rather than the reverse that is typical of C/C++ source files.

3. Terser declarations:

    ulong x;

instead of:

    unsigned long long x;

4. No ugly #preprocessor code interspersed with your nicely formatted code.

5. Nested functions mean they can be nestled close to where they are used rather than much further away in the file.

6. None of that awful

    #ifndef __INCLUDED_FOO_H
    #define __INCLUDED_FOO_H
    ...
    #endif

I already find function template syntax (1) a bit more confusing because of consecutive parentheses (I can get used to it pretty easily, but it will always be a bit slower to read), and 2–6 does not make me want to convert to D from Rust.

Metaprogramming generally involves complicated code like that. The choice is really simple: either the language allows it, and then some features can be implemented as a library (and we see the immediate benefit of that in this case, where the library can be rewritten to optimize it for some specific use-case), or else the language doesn't, and then those features have to be implemented as language constructs, or are omitted entirely.

It has some additional. Because so much code is generated on the fly during compilation, and because of frequent use of auto, IDEs have a hard time understanding the syntax to provide proper autocompletion :(

THey didn't write a new compiler. They did have some work to make their codebase work on LDC, the LLVM-backend implementation of D.

Rewriting the standard library for performance is not unique to D. Game developers famously avoid stl/stdc++ (https://github.com/electronicarts/EASTL). The reasons behind that seems to be similar: optimizing memory allocation to their specific use case.

Most high-performance shops (Google, FB, Netflix, Amazon, ...) tweak their OS, compiler, etc.

You avoid GC in D in the same way you avoid GC in C++. If you are using D to do rapid prototyping or scripting, at least you have a GC that allows you not to think about it.

If you are on a project where performance is a feature, you already think about your memory management, no matter the language. Standard library have to be generic, and will unlikely match your requirements. That said, STL's allocation strategies are a good step in the right direction in this space.

Reply on news.ycombinator.com