I've find a comment in a post comparing C++ with D and someone said that D can't be used for big projects cause you will face problems with it and the community nobody will help you other than "just don't use const", "we
haven't developed a concensus yet", "we can't convince Walter",
etc.

Is that true? And if yes can someone make some examples of what problems we're going to face? I'm asking that cause I'm learning programming (I'm close to complete my first year) and I'm planning to use D for big projects in the future and if I'm gonna have problems with that, I would like to know why. Also are there any big D project (rather than Dub and the compilers themselves of course)

On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
> problems we're going to face? I'm asking that cause I'm learning programming (I'm close to complete my first year) and I'm planning to use D for big projects in the future and if I'm gonna have problems with that, I would like to know why. Also are there any big D project (rather than Dub and the compilers themselves of course)

What do you mean by big project? Most big projects on servers break up their code-base into many smaller executables. Makes changes easier, scaling easier, debugging easier, and overall a more robust approach. That can also be the case for applications (or they break the executable into into several linkable libraries with a clean separation layer).

In general, building large executables in a system level programming language is a bad idea as the probability of there being a fatal bug in the code base will approach 1 as the code base grows. The performance you can squeeze out of a system programming language does come with high debt.

If you want to write huge applications, you are better off using a high level language like C# or Java.  Not D specific, applies to all system level languages, also C/C++.

If you want to do something with low latency and have a code base with high complexity then the stop-the-world garbage collection strategy will most certainly become an issue you will have to deal with one way or another. The probability of this becoming an issue will of course increase as the size of the application grows.

Anyway, if you are just learning programming then big-huge-projects are 10 years into the future... either that, or you will link to huge C/C++ libraries. So, you probably should not worry about that specific aspect.

On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
> I've find a comment in a post comparing C++ with D and someone said that D can't be used for big projects cause you will face problems with it and the community nobody will help you other than "just don't use const", "we
> haven't developed a concensus yet", "we can't convince Walter",
> etc.
>
> Is that true? And if yes can someone make some examples of what problems we're going to face? I'm asking that cause I'm learning programming (I'm close to complete my first year) and I'm planning to use D for big projects in the future and if I'm gonna have problems with that, I would like to know why. Also are there any big D project (rather than Dub and the compilers themselves of course)

Hi,
While working on a big and huge (>100K LOC) projects for Imo (messenger), Kaleidic Associates (London), and Tamedia (Zurich) I faced with the following problems:

1. GC uses user OS signals that may be incompatible with some Linux distributive. But it is possible to overload what signals GC should use.
2. A lot of C++ mangling bugs when interacting with C++ code.
3. DMD codegen bugs and segfaults, can be solved if you switch on LDC instead. LDC crashes too, but it happens much rarely.
4. Luck of D libraries I can use to work on the project. I solved it by working on Mir libraries with other engineers.

http://mir-algorithm.libmir.org/
http://mir-core.libmir.org/
http://asdf.libmir.org/
http://mir-optim.libmir.org/

Also, huge projects can have quite fast compilations speeds if they have good architecture and don't use Phobos (except std.traits and std.meta). In Phobos, almost everything depends on half of Phobos.

Ilya

On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:
> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>> I've find a comment in a post comparing C++ with D and someone said that D can't be used for big projects cause you will face problems with it and the community nobody will help you other than "just don't use const", "we
>> haven't developed a concensus yet", "we can't convince Walter",
>> etc.
>>

This is true. You can't count on the community. It is a kind of luck to get help for really complex issues. I just trying to do not rely on Phobos and if I am facing with compiler issue the first thing I am thinking is can I work around it somehow and without waiting that it would be fixed one day.

On Saturday, 19 December 2020 at 10:01:46 UTC, 9il wrote:
> On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:
>> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>>> I've find a comment in a post comparing C++ with D and someone said that D can't be used for big projects cause you will face problems with it and the community nobody will help you other than "just don't use const", "we
>>> haven't developed a concensus yet", "we can't convince Walter",
>>> etc.
>>>
>
> This is true. You can't count on the community. It is a kind of luck to get help for really complex issues. I just trying to do not rely on Phobos and if I am facing with compiler issue the first thing I am thinking is can I work around it somehow and without waiting that it would be fixed one day.

It's so embarrassing ... tons of argument against the balkanization of the language, and every MAJOR adopter just build everything from scratch: Weka, Sociomantic ...

We have three different Variant and Algebraic implementation, with different interface, why? Why different interface? Why not trying to play with the others?
We have two CPUID implementation, why?
I/O? Dozen
Why core building blocks are duplicated?

The fear was the balkanization of the language, and we have the balkanization of everything else.

And 9il and Symmetry were really a whide delusion in having contributed to that: everyone alone! For what? Be free, as iLya wrote one time? To not wait, as wrote here above?

Bleah ... sacrificing the medium-term vision to just have a short-term solution.

Frankly speaking, a BIG KUDOS to everyone devoted maintain, improve and keep Phobos running: you all have my total appreciation.

On Saturday, 19 December 2020 at 10:29:11 UTC, Marlon wrote:
> The fear was the balkanization of the language, and we have the balkanization of everything else.

This is common in system level programming though. Very common in C++/C. A good argument for keeping the standard library small an efficient.

On Saturday, 19 December 2020 at 09:31:14 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>> [...]
>
> What do you mean by big project? Most big projects on servers break up their code-base into many smaller executables. Makes changes easier, scaling easier, debugging easier, and overall a more robust approach. That can also be the case for applications (or they break the executable into into several linkable libraries with a clean separation layer).
>
> [...]

Yeah I think I won't make anything big for now but who knows, maybe I'll start small and evolve it as it goes. Tho I thing I understand what you talking about. Thanks a lot for your time man! Have a great day!

On Saturday, 19 December 2020 at 10:29:11 UTC, Marlon wrote:
> On Saturday, 19 December 2020 at 10:01:46 UTC, 9il wrote:
>> On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:
>>> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>>>> I've find a comment in a post comparing C++ with D and someone said that D can't be used for big projects cause you will face problems with it and the community nobody will help you other than "just don't use const", "we
>>>> haven't developed a concensus yet", "we can't convince Walter",
>>>> etc.
>>>>
>>
>> This is true. You can't count on the community. It is a kind of luck to get help for really complex issues. I just trying to do not rely on Phobos and if I am facing with compiler issue the first thing I am thinking is can I work around it somehow and without waiting that it would be fixed one day.
>
> It's so embarrassing ... tons of argument against the balkanization of the language, and every MAJOR adopter just build everything from scratch: Weka, Sociomantic ...

I didn't fork the language. I am backing libraries. It is a different things.

> We have three different Variant and Algebraic implementation, with different interface, why? Why different interface? Why not trying to play with the others?

There are four implementations I know. Phobos, Vibe.d, Sumtype and mir.algebraic from mir-core. I have reviewed the first three before I decided it would be faster to write mir.algebraic. Nothing personal, just time & money. I am writing code faster than explaining to people why this and that should be changed that way and not another.

> We have two CPUID implementation, why?

core.cpuid is buggy and has an unmaintainable complex and verbose implementation. And API isn't well as it can be. So, we have mir-cpuid. Why? because I needed a good cpuid library to finish my job.

> I/O? Dozen

Hmm, for example, `io` is @nogc. It is a huge benefit.

> Why core building blocks are duplicated?

For example, Phobos number parsing isn't precise. Phobos lacks the Ryu algorithm for number printing. Phobos uses the C library for more than half of the printing cases. Phobos big integer arithmetic is monstrous and too high level (that means very slow in practice) to the real-world tasks I am working on.

> The fear was the balkanization of the language, and we have the balkanization of everything else.

Code means nothing. People are everything. Code reflects people's relationships and expertise.

> And 9il and Symmetry were really a whide delusion in having contributed to that: everyone alone! For what? Be free, as iLya wrote one time? To not wait, as wrote here above?

Yes, that is the problem. And don't need to blame people and companies that they don't want to spend their time and money investing in Phobos. BTW, Symmetry supports works on the compiler, DRuntime, and Mir. That is the Dlang Foundation problem that people and companies invest in their solutions instead of work together under DLF umbrella. Have you thought of why? Do you really think, for example, I want to create these libraries? No, I wanted to get my job done and go walk with my dog.

The fact is that I did a lot of contributions to Phobos and then I created std.experimental.ndslice, which was accepted. Quite sad. But I don't want to put my efforts into Phobos anymore. I can code because companies pay money, and moving code to Phobos means work more, get less, and play in the sandbox I don't want and don't need to play. If the sandbox needs me to play in, it can change the rules. My experience with current rules was negative but informative.

Ilya

On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:
> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>> [...]
>
> Hi,
> While working on a big and huge (>100K LOC) projects for Imo (messenger), Kaleidic Associates (London), and Tamedia (Zurich) I faced with the following problems:
>
> [...]

Wait, isn't Phobos the runtime that comes with D? Because I don't know how it works exactly, how you don't use it? And how do you do stuff?

On Saturday, 19 December 2020 at 11:44:18 UTC, Godnyx wrote:
> On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:
>> On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:
>>> [...]
>>
>> Hi,
>> While working on a big and huge (>100K LOC) projects for Imo (messenger), Kaleidic Associates (London), and Tamedia (Zurich) I faced with the following problems:
>>
>> [...]
>
> Wait, isn't Phobos the runtime that comes with D? Because I don't know how it works exactly, how you don't use it? And how do you do stuff?

DRuntime is core.*, it includes GC.
Phobos is std.*, it includes most of the everyday stuff.

I am doing stuff with mir.*, core.lifetime, std.traits, and std.meta, core.stdc.*.

That all I need. I use Phobos in some cases, but not for big projects except for debugging purposes.

One of the huge projects I have done is 100% @nogc. It doesn't even initialize GC. So, you can be sure it is possible, but may not be easy. mir.rc package from mir-algorithm is used for ref-counted memory managment.