Why is D unpopular?

[Alexandru Ermicioi]

On Saturday, 11 June 2022 at 11:24:04 UTC, forkit wrote:
> The module is not a type!
>
> I do not design my solution around the module. I design it 
> around types, and I use the module to bring related types 
> together.

Then don't use module to bring related types yet not tightly 
coupled ones toghether. Use rather packages. It seems that your 
definition of module is more matching to a package in D rather 
than D module.

It is indeed pain sometimes to have to create new modules, but 
you can argue that it is also pain to skim through thousands of 
lines of code in a single module.

> Separate, unrelated types can go in their own module.
>
> In the event a type (and I'm talking about an instatiation of 
> class here) - is a standalone type.. sure..it can go it's own 
> module, no problem. Makes sense even.
>
> But you don't have to put every int your define into its own 
> module, just so the compiler can enforce its invariants. That 
> would be crazy.. yes?

Why not? Why crazy?

Usually a type (class/struct) is not just a single or two lines, 
but 10-20 at least. Imho it is perfectly fine to put them in 
single file. In java, that is how it is done, one file one public 
class.

> A class is just a type - why is it considered less a type than 
> an int? (i.e. the only way to protect its invariants, is to put 
> it all by itself in its own module.
>
> What utter nonsense!

Obviously you're comparing apples with grapes. int is a built-in 
type and certainly not a class or struct, although making the 
builtin-types and user defined ones have homogeneous rules 
mostly, would be beneficial.

> The module is not a type. You do not design your solution using 
> types.
>
> You do not instatiate a module, and start sending it messages, 
> or recieve messages from it, or change its behavior, or have it 
> change its own behavior.
>
> The module is a just convenient static encapsulation for 
> related types.

Well, why can't it be?
You certainly can consider it being a singleton per thread, where 
global vars are it's internal state, and exported functions are 
the methods to class (module). Certainly it doesn't have 
inheritance and other OOP aspects, but saying that module is a 
bunch of related types only, is not right. Better to say, is that 
they are bunch of tightly coupled types, meaning that extracting 
one type into separate module most certainly would require the 
other types in module to be adjusted to the change (not by 
importing the new module, but actual code changes).

In summary, the current access modifiers, don't make oop 
programming in D in any way less powerful, than any other 
language with comparable oop features.

Best regards,
Alexandru.