Real D

Quirin Schroll qs.il.paperinik at gmail.com
Thu Apr 25 14:23:12 UTC 2024


On Tuesday, 23 April 2024 at 14:56:50 UTC, Marconi wrote:
> On Sunday, 21 April 2024 at 03:47:08 UTC, ShowMeTheWay wrote:
>> These two approaches are difficult to reconcile, 
>> philosophically ;-)
>
> Vlang - Simple language for building maintainable programs
> Ziglang - Focus on debugging your application rather than 
> debugging your programming language knowledge. (simple, 
> maintainable)
> Rust - Reliable and efficient software.
> C++ - C with Zero Cost Abstraction
> D - D shines from low-level control to high-level abstraction. 
> Fast code, [running?]fast.
> C - Simple. Efficiency. Close-to-Hardware Programming. "Nothing 
> is better than C" "When i see C, i see the assembler" - Linus
> Java - "Write once, run anywhere." Not so true, but work great 
> in terms of propaganda. GUI in java sucks, its better create 
> different efficient programs for each system than just a one 
> bad java software. What Java really has great its a big 
> standard API.
>
> So, the right order of principles:
> Simple (maintainable), fast, big organized standard library.
>
> That's why C still shines. Its still simple and fast.
> Thats's why everybody wants replace C++. Its fast, but hard to 
> learn and mantain.
> Thats's why everybody wants replace Java. Its simple, but slow.
> Thats's why Rust is growing but will die. Its fast, but hard 
> and becoming more and more hard.
>
> If D create some new way to make manual memory management 
> easily, in such a way that the lovers of GC would not be so 
> furious... the language could reach almost the perfection.
>
> Default GC was the biggest D mistake.

Only a propaganda mistake. For most applications, the kind of 
memory management is largely irrelevant as long as there is no 
leak. GC at CTFE is brilliant. C++ tries to do manual memory 
management at CTFE (called `constexpr` functions) and it took 
them almost 10 years to get it done (C++11 introduced `constexpr` 
and C++20 had `constexpr` dynamic memory allocation), and even 
there, e.g. a `std::vector` can’t leave the CTFE environment and 
become a compile-time constant.
In D, if I need a compile-time array of non-trivial 
pre-calculated values that can be generated by some function, I 
can do this:
```d
static immutable int[] values = {
     int[] result;
     // algorithm fills `result`
     return result;
}(); // runs at ctfe
```
If I want or need to, I can convert this to a static array:
```d
enum int[] _values = {…}();
static immutable int[_values.length] values = _values;
```
This runs at compile-time guaranteed. It’s not an optimization. 
As far as I know, this is not easily done in C++. It’s certainly 
doable using templates, but it’s not doable in C++23 using 
non-template `constexpr` functions and e.g. `std::vector`.

If you don’t want the GC to run, use `@nogc` or full-on 
`-betterC`. Even in BetterC mode, you can use all of D’s features 
like GC at CTFE.


More information about the Digitalmars-d mailing list