www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can D used for BIG-HUGE projects?

reply Godnyx <rempas tutanota.com> writes:
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)
Dec 19 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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 

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.
Dec 19 2020
parent Godnyx <rempas tutanota.com> writes:
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!
Dec 19 2020
prev sibling next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
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
Dec 19 2020
next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
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.
Dec 19 2020
parent reply Marlon <marlon gmail.com> writes:
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.
Dec 19 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Dec 19 2020
prev sibling next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
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
Dec 19 2020
next sibling parent reply Marlon <marlon gmail.com> writes:
On Saturday, 19 December 2020 at 11:44:16 UTC, 9il wrote:

 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


So taking only the good parts, assembled by people that 'spent 
their time' trying to design a coherent and top-class design is 
fine. Playing in the sandbox no, because you design and code 
better and faster than the others. 'Nothing personal, just time & 
money' Bleah again ...

'Code means nothing. People are everything. Code reflects 
people's relationships and EXPERTISE' Clap clap, bleah ... you 
can try to be a little more humble, dude.

Instead of Ilya the Lone Renger, the language needs more people 
like Andrei, with his attitude towards improving things but under 
the same hat, but we know how ended ...

Balkanization, all the way down, like turtles: try to build 
something BIG-HUGE as the author asked, mixing together all the 
different pieces. A little of sumtype, a little of MIR, a little 
of phobos, and a little of vibe ... it's like nitro, handle with 
care!

Atila, knock knock, there's anybody in there? And everyone is 
wondering why D is not growing fast enough?
Dec 19 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 Instead of Ilya the Lone Renger, the language needs more people 
 like Andrei, with his attitude towards improving things but 
 under the same hat, but we know how ended ...


This is wrong. Good libraries grow out of existing applications. 
Conjouring libraries out of a theoretical void (or the mood of 
the day) tends to lead a mismatch with what people try to achieve.

Ilya is doing the right thing. If you want to improve libraries 
you should look at what people use in finished applications and 
abstract over that.
Dec 19 2020
parent reply Marlon <marlon gmail.com> writes:
On Saturday, 19 December 2020 at 12:30:00 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 Instead of Ilya the Lone Renger, the language needs more 
 people like Andrei, with his attitude towards improving things 
 but under the same hat, but we know how ended ...


 This is wrong. Good libraries grow out of existing 
 applications. Conjouring libraries out of a theoretical void 
 (or the mood of the day) tends to lead a mismatch with what 
 people try to achieve.

 Ilya is doing the right thing. If you want to improve libraries 
 you should look at what people use in finished applications and 
 abstract over that.


I'm talking about basic building blocks. See the "nitro" part of 
the message.
Good luck mixing thing together, if you need something outside of 
the lone ranger sandbox.
Dec 19 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 12:33:47 UTC, Marlon wrote:

 I'm talking about basic building blocks. See the "nitro" part 
 of the message.
 Good luck mixing thing together, if you need something outside 
 of the lone ranger sandbox.


The only basic building blocks that matter are the ones that 
occur in interfaces. So D desperately needs a flexible and 
efficient way to convey ownership for instance, allowing 
libraries to transfer ownership of resources. Same thing with 
ensuring thread local ownership and what the memory model 
implies. So I think there is language spec work to be done before 
completing solid basic building blocks, unfortunately.
Dec 19 2020
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 On Saturday, 19 December 2020 at 11:44:16 UTC, 9il wrote:

 [...]


 So taking only the good parts, assembled by people that 'spent 
 their time' trying to design a coherent and top-class design is 
 fine. Playing in the sandbox no, because you design and code 
 better and faster than the others. 'Nothing personal, just time 
 & money' Bleah again ...

 'Code means nothing. People are everything. Code reflects 
 people's relationships and EXPERTISE' Clap clap, bleah ... you 
 can try to be a little more humble, dude.

 Instead of Ilya the Lone Renger, the language needs more people 
 like Andrei, with his attitude towards improving things but 
 under the same hat, but we know how ended ...

 Balkanization, all the way down, like turtles: try to build 
 something BIG-HUGE as the author asked, mixing together all the 
 different pieces. A little of sumtype, a little of MIR, a 
 little of phobos, and a little of vibe ... it's like nitro, 
 handle with care!

 Atila, knock knock, there's anybody in there? And everyone is 
 wondering why D is not growing fast enough?


I am not native speaker but your post sounds rather aggressive 
and insulting.
Please consider expressing your opinion in a more friendly way.

Here is my opinion: trying to bring numpy / pandas to the D 
language is a huge task and will be a game changer for D. What 
Ilya and the other Mir developers doing here is huge and really 
important for D. I doubt this can be done in Phobos at the first 
place, but there is of course the possibility to port it from Mir 
to Phobos at a later point in time.

We should be more thankful to the developers who make such a 
great job.

Kind regards
Andre
Dec 19 2020
parent reply Marlon <marlon gmail.com> writes:
On Saturday, 19 December 2020 at 12:40:40 UTC, Andre Pany wrote:

 On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 On Saturday, 19 December 2020 at 11:44:16 UTC, 9il wrote:

 [...]


 So taking only the good parts, assembled by people that 'spent 
 their time' trying to design a coherent and top-class design 
 is fine. Playing in the sandbox no, because you design and 
 code better and faster than the others. 'Nothing personal, 
 just time & money' Bleah again ...

 'Code means nothing. People are everything. Code reflects 
 people's relationships and EXPERTISE' Clap clap, bleah ... you 
 can try to be a little more humble, dude.

 Instead of Ilya the Lone Renger, the language needs more 
 people like Andrei, with his attitude towards improving things 
 but under the same hat, but we know how ended ...

 Balkanization, all the way down, like turtles: try to build 
 something BIG-HUGE as the author asked, mixing together all 
 the different pieces. A little of sumtype, a little of MIR, a 
 little of phobos, and a little of vibe ... it's like nitro, 
 handle with care!

 Atila, knock knock, there's anybody in there? And everyone is 
 wondering why D is not growing fast enough?


 I am not native speaker but your post sounds rather aggressive 
 and insulting.
 Please consider expressing your opinion in a more friendly way.


So, saying that time and money is what really matter, in an open 
source project, is not aggressive? Geez ... well, everyone has 
its values, I still on the side of who effortlessly put its time 
in trying to grow the WHOLE ecosystem in an harmonic grow.


Here is my opinion: trying to bring numpy / pandas to the D
 language is a huge task and will be a game changer for D. What 
 Ilya and the other Mir developers doing here is huge and really 
 important for  D.


I do not care about numpy and pandas, I care about 4 (thank you 
Ilya) different INCOMPATIBLE ways of implementing Algebraic. Not 
a rocket, Algebraic. As it seems that everybody needs to 
implement it from scratch every time to do his homework, I would 
call it a basic building block.


 We should be more thankful to the developers who make such a 
 great job.


And we should. And I could curse them every time I can't mix 
easily their beautiful job with other beautiful job, because of 
'money and time'.
Dec 19 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 22:37:36 UTC, Marlon wrote:

 I do not care about numpy and pandas, I care about 4 (thank you 
 Ilya) different INCOMPATIBLE ways of implementing Algebraic. 
 Not a rocket, Algebraic. As it seems that everybody needs to 
 implement it from scratch every time to do his homework, I 
 would call it a basic building block.


Meh, it should be a language feature. Also, untagged union is 
creating problems for precise GC, that is a serious design flaw 
for a language that relies on GC.
Dec 19 2020
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.12.20 23:37, Marlon wrote:

 On Saturday, 19 December 2020 at 12:40:40 UTC, Andre Pany wrote:

 On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 On Saturday, 19 December 2020 at 11:44:16 UTC, 9il wrote:

 [...]


 So taking only the good parts, assembled by people that 'spent their 
 time' trying to design a coherent and top-class design is fine. 
 Playing in the sandbox no, because you design and code better and 
 faster than the others. 'Nothing personal, just time & money' Bleah 
 again ...

 'Code means nothing. People are everything. Code reflects people's 
 relationships and EXPERTISE' Clap clap, bleah ... you can try to be a 
 little more humble, dude.

 Instead of Ilya the Lone Renger, the language needs more people like 
 Andrei, with his attitude towards improving things but under the same 
 hat, but we know how ended ...

 Balkanization, all the way down, like turtles: try to build something 
 BIG-HUGE as the author asked, mixing together all the different 
 pieces. A little of sumtype, a little of MIR, a little of phobos, and 
 a little of vibe ... it's like nitro, handle with care!

 Atila, knock knock, there's anybody in there? And everyone is 
 wondering why D is not growing fast enough?


 I am not native speaker but your post sounds rather aggressive and 
 insulting.
 Please consider expressing your opinion in a more friendly way.


 
 So, saying that time and money is what really matter, in an open source 
 project, is not aggressive?


No. Do you think "open source" means "waste time and money"?
How is it "aggressive" to be truthful about not being able to afford 
working for free while that work is being sabotaged by bureaucracy?


 Geez ... well, everyone has its values, I 
 still on the side of who effortlessly put its time in trying to grow the 
 WHOLE ecosystem in an harmonic grow.
 ...


I'd rather have variety and competition than people leaving because they 
do not agree with some central authority's vision.
Dec 20 2020
prev sibling parent Guillaume Piolat <first.name guess.com> writes:
On Saturday, 19 December 2020 at 12:16:46 UTC, Marlon wrote:

 Instead of Ilya the Lone Renger, the language needs more people 
 like Andrei, with his attitude towards improving things but 
 under the same hat, but we know how ended ...


Ilya has a point, it is sometimes less effort to use and maintain 
your own version than contributing back!

It is simply an economical problem and somehow I'm sure people 
are happy to have created their own "balkanized" library so that 
they have more control on memory, speed, and  nogc.

If you are building something HUGE you will end up managing 
dependencies and cutting links that create debt; that may mean 
having your own wheel you control perfectly.

For example, in Dplug we couldn't possibly use the FFT from 
Phobos, which has a range of problems _from our point of view_, 
as a general purpose library Phobos is not to blame and it fits 
its design goals. So no problem with expending effort to maintain 
`pfft`, which incidentally is larger and more complex ; it 
wouldn't fit Phobos.
Dec 19 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Saturday, 19 December 2020 at 11:44:16 UTC, 9il wrote:

 On Saturday, 19 December 2020 at 10:29:11 UTC, Marlon wrote:



 I didn't fork the language. I am backing libraries. It is a 
 different things.
 ...
 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.


I kind of agree with 9il on this and I'm sure if I could roll my 
own stuff in such a situation, I would have done that myself. 
Phobos isn't really turned for that level of performance and 100% 
nogc use case. I'm quite happy about the work Symmetry is doing 
in contribution to the packages and ecosystem overall. It gives 
everyone the opportunity to use whatever they want. I personally 
see nothing wrong with pulling a package from dub vs phobos.


I've seen over and over here how folks complain about the pain 
and process around getting anything in phobos.
Dec 19 2020
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 19 December 2020 at 10:29:11 UTC, Marlon wrote:

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


That's not really a very accurate description of what Sociomantic 
did.  Remember, Sociomantic started when D1 was the stable 
version, and used the then de-facto standard library -- Tango.  
In time that was blended into Sociomantic's in-house standard 
library, Ocean (IIRC as a precursor to open sourcing the latter, 
because by that time there was no D2 version of Tango in active 
maintenance).

The reason for not using Phobos was because by the time the D2 
migration was completed (which took a LONG time), there was a 
very large codebase, and no strong motivation to migrate away 
from a known quantity.  But any concerns about Phobos performance 
or suitability should be considered in the context that 
Sociomantic was dealing with some pretty extreme performance 
challenges.  The existing codebase had been battle tested to a 
very high degree, and naturally one tends to want to keep what 
one knows works.

The attitude in any case was not "We can't/shouldn't use Phobos" 
but "We have to be very careful about incrementally transitioning 
what features seem appropriate, because we want to keep the 
performance levels we already have."  Had Sociomantic started 
when D2 and Phobos were stable, I'm pretty sure that's what would 
have been used, and there would have been correspondingly more 
upstream collaboration and contribution.
Dec 24 2020
prev sibling next sibling parent reply Godnyx <rempas tutanota.com> writes:
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?
Dec 19 2020
parent reply 9il <ilyayaroshenko gmail.com> writes:
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.
Dec 19 2020
parent Godnyx <rempas tutanota.com> writes:
On Saturday, 19 December 2020 at 11:56:31 UTC, 9il wrote:

 On Saturday, 19 December 2020 at 11:44:18 UTC, Godnyx wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 [...]


 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.


Oh now everything makes sense!!! Thanks a lot man! I'll keep 
everything you said in mind and I'll follow it! I truly wish you 
to have a great day!
Dec 19 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


Geeze, by that definition my hobby code I wrote by myself is a 
"big and huge" project.
Dec 19 2020
next sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Saturday, 19 December 2020 at 22:53:40 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 Geeze, by that definition my hobby code I wrote by myself is a 
 "big and huge" project.


Agreed, this why I explicitly wrote what size I mean.
Dec 19 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is a "big
 and huge" project.


Yeah 100K LOC is not very much at all.  The codebase I work on at my day
job is >1.2M LOC and takes about 20-30 mins to build. No D, though,
unfortunately, just C, C++, Java, JS, and a bit of Tcl.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Dec 19 2020
next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is a 
 "big and huge" project.


 Yeah 100K LOC is not very much at all.  The codebase I work on 
 at my day job is >1.2M LOC and takes about 20-30 mins to build. 
 No D, though, unfortunately, just C, C++, Java, JS, and a bit 
 of Tcl.


 T


Geeze, did you wrote at least >1M of that codebase yourself? If 
so, that is really awesome!
Dec 19 2020
next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Sunday, 20 December 2020 at 03:26:17 UTC, 9il wrote:

 On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is 
 a "big and huge" project.


 Yeah 100K LOC is not very much at all.  The codebase I work on 
 at my day job is >1.2M LOC and takes about 20-30 mins to 
 build. No D, though, unfortunately, just C, C++, Java, JS, and 
 a bit of Tcl.


 T


 Geeze, did you wrote at least >1M of that codebase yourself? If 
 so, that is really awesome!


... I can be a badass sometimes. Nevermind. In terms of a single 
human life, 100K is a huge project one may need a year or few to 
make this project ready for production.

A command can be larger than a few men, then you can have almost 
any size if the solid system architecture allows it. A browser 
usually a project of projects. This is also valid for my work 
where "my" "huge" 100K LOC project is just a ... plugin! But for 
me, it is "huge" and I am very happy I have done it.
Dec 20 2020
parent bachmeier <no spam.net> writes:
On Sunday, 20 December 2020 at 17:29:50 UTC, 9il wrote:


 ... I can be a badass sometimes. Nevermind. In terms of a 
 single human life, 100K is a huge project one may need a year 
 or few to make this project ready for production.

 A command can be larger than a few men, then you can have 
 almost any size if the solid system architecture allows it. A 
 browser usually a project of projects. This is also valid for 
 my work where "my" "huge" 100K LOC project is just a ... 
 plugin! But for me, it is "huge" and I am very happy I have 
 done it.


Lines of code is a horrible way to measure the size of a project. 
Some projects have computer generated code. sqlite is 143K LOC. 
The test suite is nearly 100M LOC, but very little was written by 
humans, so should you count the test suite or the code to 
generate the test suite? Some languages have tons of boilerplate. 
Some code solves complex problems, while some is tens of 
thousands of lines automating trivial activities (a great use of 
the computer, but that doesn't make it "big"). Then there's the 
removal of lines of code, optimization, testing, writing 
documentation, external interfacing, answering questions, etc. 
All of *that* is what factors into the size of a software 
project, not a simple measure of LOC.
Dec 20 2020
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Dec 20, 2020 at 03:26:17AM +0000, 9il via Digitalmars-d wrote:

 On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:


[...]

 Yeah 100K LOC is not very much at all.  The codebase I work on at my
 day job is >1.2M LOC and takes about 20-30 mins to build. No D,
 though, unfortunately, just C, C++, Java, JS, and a bit of Tcl.




[...]

 Geeze, did you wrote at least >1M of that codebase yourself? If so,
 that is really awesome!


Haha, no.  It's written by a large team of people over many years' time.
I'm just an employee.


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about
all I can take." -- Calvin & Hobbes
Dec 20 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is a 
 "big and huge" project.


 Yeah 100K LOC is not very much at all.  The codebase I work on 
 at my day job is >1.2M LOC and takes about 20-30 mins to build. 
 No D, though, unfortunately, just C, C++, Java, JS, and a bit 
 of Tcl.


Why all of those BTW? Are they different applications?
Dec 20 2020
prev sibling next sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is a 
 "big and huge" project.





 Yeah 100K LOC is not very much at all.  The codebase I work on 
 at my day job is >1.2M LOC and takes about 20-30 mins to build. 
 No D, though, unfortunately, just C, C++, Java, JS, and a bit 
 of Tcl.


 T


<follow up comment>
https://forum.dlang.org/post/ergsydggaqmvybuhspni forum.dlang.org
Dec 20 2020
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 On Sat, Dec 19, 2020 at 10:53:40PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote:

 On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 big and huge (>100K LOC) projects


 
 Geeze, by that definition my hobby code I wrote by myself is a 
 "big and huge" project.


 Yeah 100K LOC is not very much at all.  The codebase I work on 
 at my day job is >1.2M LOC and takes about 20-30 mins to build. 
 No D, though, unfortunately, just C, C++, Java, JS, and a bit 
 of Tcl.


 T


Same for me. Our codebase at work is roughly similar in size, 
mostly Java/Groovy with small components written in C++ and Go. 
It's actually really nice how easy it is to navigate the Java 
code in IntelliJ - only once have I had an issue finding where 
some old functionality was implemented, and that was because the 
code was loading classes at runtime from another module with 
nothing to indicate the connection between it and that module. 
When I think about trying to trace the flow of execution through 
a big D project, most of which I didn't write, that makes heavy 
use of metaprogramming... I think it would be far more painful.
Dec 21 2020
parent aberba <karabutaworld gmail.com> writes:
On Monday, 21 December 2020 at 17:00:52 UTC, Meta wrote:

 On Sunday, 20 December 2020 at 03:06:21 UTC, H. S. Teoh wrote:

 [...]


 Same for me. Our codebase at work is roughly similar in size, 
 mostly Java/Groovy with small components written in C++ and Go. 
 It's actually really nice how easy it is to navigate the Java 
 code in IntelliJ - only once have I had an issue finding where 
 some old functionality was implemented, and that was because 
 the code was loading classes at runtime from another module 
 with nothing to indicate the connection between it and that 
 module. When I think about trying to trace the flow of 
 execution through a big D project, most of which I didn't 
 write, that makes heavy use of metaprogramming... I think it 
 would be far more painful.


I wish to know more from folks using D... about their experience 
with heavily templated codebase maintenance without tooling 
support.
Dec 24 2020
prev sibling parent Calvin P <cloudlessapp gmail.com> writes:
On Saturday, 19 December 2020 at 09:53:47 UTC, 9il wrote:

 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


+1

My 148225 line betterC code build without cache in few seconds.
Dec 19 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
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)



It's all opinion based. And you should consider the kind of devs 
who share that opinion. Mostly system developers (I guess... 
still don't know their use cases for D... needs a survey of some 
kind) My observation is they kind of have the habit of 
criticizing the technicality of existing implementations ... Cus 
they can roll their own implementation?? I'm not dismissing that 
sometimes their use case may warrants it. But that's up to those 
system developers.


Personally (considering what I use D for... Web, APIs, Scripting, 
GUI, data processing, prototyping ideas) I see D as more than 
capable of nailing any problem I have. It's ridiculously to 

terms of capability. And those are the most well know langs.

The only thing D lacks compared to any of those major languages 
is marketing, tutorials (learning resources) and the number of 
packages we have. PM stuff too.

These days the packages available on dub is good enough for most 
things I do.
Dec 19 2020
prev sibling parent reply sighoya <sighoya gmail.com> writes:
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",


This relates mostly, I think, to using const in class 
inheritance. But using them in functions makes pretty sense.
Part of the problem D's initial design as a mutable language like 
C, C++ or Java. For instance equals in Object check on mutable 
values, but because equals doesn't change any objects their 
params should be made const, but that wasn't possible afterwards 
due to backward compatibility?
Here are some nice links (the last is a discussion about known 
issues):

https://dlang.org/spec/const3.html
https://dlang.org/articles/const-faq.html
https://forum.dlang.org/thread/2735451.YHZktzbKJo lyonel


"we haven't developed a concensus yet",


I don't know exactly to which context this refers, nevertheless I 
could imagine it refers to the future direction of D. We have a 
new project leader atila neves, maybe he knows more about that.


"we can't convince Walter"


D powerful but conservative these days regarding feature 
implementations that change the lang. This can be good or bad. 
Most of the time, I feel this is right (especially relating to 
D's simple grammar), but not always. But this is an issue in each 
language these days and D don't want to become the next C++.





 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)


Is it possible to develop big projects in D?
yes

Are there any problems to deal with?
yes, like in any language.
For D, I would first define a suitable convention how should be 
developed, i.e. which concepts should be used.
I find this to be important because D offers many ways to 
implement algorithms.
Did the project tend more to OOP or more to generic programming 
or to a mix of boths?

It depends further on your needs, when you are interested in 
speed and control, Dlang is the right choice.

It also depends on library support, does D offer the lib I want? 
When not, can I link my D app against C++ lib (yes) and what are 
the costs to deal with C++ libs+headers or what are the costs to 
write it from scratch in D?
Note that D offers some support for C++ integration in the 
language.

This is often in Java as Java has everything and is platform 
independent whereas D and C++ libs need to be compiled. This 
works good in D but is horrible when you compile a C++ project 
from source in case you can't acquire any binary.

Maybe you should write something about your needs for your big 
project or is this a general question?

If so, D can do it.
Dec 21 2020
next sibling parent sighoya <sighoya gmail.com> writes:
This is often in Java as Java has everything


Ah damn it, I meant library support in Java is often easier as 
Java has everything ...

Sorry.
Dec 21 2020
prev sibling parent Deslt <deslt.desmond gmail.com> writes:
On Monday, 21 December 2020 at 20:16:24 UTC, sighoya wrote:

 On Saturday, 19 December 2020 at 09:13:00 UTC, Godnyx wrote:

"we can't convince Walter"


 D powerful but conservative these days regarding feature 
 implementations that change the lang. This can be good or bad. 
 Most of the time, I feel this is right (especially relating to 
 D's simple grammar), but not always. But this is an issue in 
 each language these days and D don't want to become the next 
 C++.



Whenever I hear this spoken, it isn't only about adding a new 
feature. It is just general project management as well. It seems 
the D team has trouble removing old broken legacy code/tools 
because Walter doesn't want to remove it. Even things like just 
refactoring code to make it easier to read and maintain. Hell 
Andrei wrote up a whole page when they finally replaced the 
broken make files.

Another good example was someone that does work with D 
professional posting their experience with D's release 
versioning. How there's no long term or stable support. A big 
project is going to be maintained for a long time. Walter's 
response was that D doesn't need it.

This inhibits growth and I definitely wouldn't recommend using D 
for a big project for this reason. Unless you want to deal with 
completely avoidable headaches cause one person couldn't be 
convinced.
Dec 26 2020