December 19, 2020
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!
December 19, 2020
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?


December 19, 2020
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.

December 19, 2020
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.


December 19, 2020
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
December 19, 2020
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.



December 19, 2020
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 suggest that JavaScript, Python, C# and Java compares to D in 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.
December 19, 2020
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.




December 19, 2020
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.

December 19, 2020
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'.