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.

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

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.

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.

>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.

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.

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.

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.