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