Jump to page: 1 2 3
Thread overview
Status of std.container rewrite?
Jun 07, 2020
Rahul Gupta
Jun 07, 2020
Rahul Gupta
Jun 07, 2020
Seb
Jun 07, 2020
mw
Jun 07, 2020
aberba
Jun 07, 2020
aberba
Jun 08, 2020
Atwork
Jun 10, 2020
Seb
Jun 10, 2020
Avrina
Jun 10, 2020
tsbockman
Jun 07, 2020
mw
Jun 08, 2020
exo1
Jun 09, 2020
tsbockman
Jun 09, 2020
tastyminerals
Jun 09, 2020
tsbockman
Jun 10, 2020
tastyminerals
Jun 10, 2020
Russel Winder
Jun 10, 2020
tastyminerals
Jun 10, 2020
Avrina
Jun 10, 2020
Russel Winder
Jun 09, 2020
tastyminerals
June 07, 2020
Hello,

(Sorry, if i posted to wrong forum)

I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.

Looking at std.containers I see that it is very barebones and generally requires a lot of efforts to use. Googling around brings me to stuff posted around 2015-16 that says that std.container is pending a rewrite. However it is 2020 now and std.container has still not improved.

Has any progress made towards the rewrite? Is it at design stage or being developed or has it been forgotten? Is there any timeline for the std.containers rewrite?
June 07, 2020
Also, I have seen https://github.com/dlang-community/containers which is in much better shape than std.container.

However, being outside of the stdlib means that it cannot be used in competitive programming contests. My friends and I sometimes compete against each other and I was hoping to use D :(
June 07, 2020
On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
> Hello,
>
> (Sorry, if i posted to wrong forum)
>
> I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.
>
> Looking at std.containers I see that it is very barebones and generally requires a lot of efforts to use. Googling around brings me to stuff posted around 2015-16 that says that std.container is pending a rewrite. However it is 2020 now and std.container has still not improved.
>
> Has any progress made towards the rewrite? Is it at design stage or being developed or has it been forgotten? Is there any timeline for the std.containers rewrite?

The latest effort was https://github.com/dlang/druntime/pull/2760, but it stalled as no consensus was reached on how the reference-counting should be done.

June 07, 2020
On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
>
> I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.

The D language feature is great, however the library has some problems.

But you can always use language *built-in* containers: array, Associative Arrays

https://dlang.org/spec/arrays.html
https://dlang.org/spec/hash-map.html

to get most things done, also there are algorithms in the std library:

https://dlang.org/phobos/std_algorithm.html
https://dlang.org/phobos/std_range.html

For small programs, these built-ins normally are good enough.

If you do want to use D in your project (instead of having competition restrictions), you can check

https://code.dlang.org/

for user contributed libraries. If you still can’t find what you want, then you need to have some hacker spirit to write you own libraries. Welcome to the D world :-)


June 07, 2020
On Sunday, 7 June 2020 at 19:49:48 UTC, Seb wrote:
> On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
>> Hello,
>>
>> (Sorry, if i posted to wrong forum)
>>
>> I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.
>>
>> Looking at std.containers I see that it is very barebones and generally requires a lot of efforts to use. Googling around brings me to stuff posted around 2015-16 that says that std.container is pending a rewrite. However it is 2020 now and std.container has still not improved.
>>
>> Has any progress made towards the rewrite? Is it at design stage or being developed or has it been forgotten? Is there any timeline for the std.containers rewrite?
>
> The latest effort was https://github.com/dlang/druntime/pull/2760, but it stalled as no consensus was reached on how the reference-counting should be done.


D has never failed to amaze me everyday.

Suppose we are a company: our customers knock on our door want to do some business with us. Since the product is a new (? 20 years) language, the customers naturally want we provide std libraries with the language. But our message to our customers is: sorry, the library PR is 10 months old, and with unknown date it could be merged, if at all.

I’m just wondering if the customers will just leave us and knock the next door :-( (and there are a number of competitors as replacement of C++ on the market)

Sigh, this is our reality in terms of expanding D’s adoption.

Can we put stabilizing the compiler & libraries as our top priority? or at least improve our PR with better messages to our potential language users?



June 07, 2020
On Sunday, 7 June 2020 at 19:49:48 UTC, Seb wrote:
> On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
>> Hello,
>>
>> (Sorry, if i posted to wrong forum)
>>
>> I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.
>>
>> Looking at std.containers I see that it is very barebones and generally requires a lot of efforts to use. Googling around brings me to stuff posted around 2015-16 that says that std.container is pending a rewrite. However it is 2020 now and std.container has still not improved.
>>
>> Has any progress made towards the rewrite? Is it at design stage or being developed or has it been forgotten? Is there any timeline for the std.containers rewrite?
>
> The latest effort was https://github.com/dlang/druntime/pull/2760, but it stalled as no consensus was reached on how the reference-counting should be done.


The technically of the community is both a blessing and a curse. Part of why most things never end up in upstream. std_data_json, dxml, ...?? A perfect solution that never comes.

Dub was bashed so many times now its what we~ all use.

Something is definitely broken in decision making around tools and ecosystem improvement.
June 07, 2020
On Sunday, 7 June 2020 at 22:00:32 UTC, aberba wrote:
> On Sunday, 7 June 2020 at 19:49:48 UTC, Seb wrote:
>> On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
>>> [...]
>>
>> The latest effort was https://github.com/dlang/druntime/pull/2760, but it stalled as no consensus was reached on how the reference-counting should be done.
>
>
> The technically of the community is both a blessing and a curse. Part of why most things never end up in upstream. std_data_json, dxml, ...?? A perfect solution that never comes.
>
> Dub was bashed so many times now its what we~ all use.
>
> Something is definitely broken in decision making around tools and ecosystem improvement.

Technicality* Jeez, I hate myself
June 08, 2020
On Sunday, 7 June 2020 at 22:00:32 UTC, aberba wrote:
> On Sunday, 7 June 2020 at 19:49:48 UTC, Seb wrote:
>> On Sunday, 7 June 2020 at 18:39:22 UTC, Rahul Gupta wrote:
>>> Hello,
>>>
>>> (Sorry, if i posted to wrong forum)
>>>
>>> I am new to D, just started learning a few days back. I have been writing small programs to learn D, some of which require use of containers.
>>>
>>> Looking at std.containers I see that it is very barebones and generally requires a lot of efforts to use. Googling around brings me to stuff posted around 2015-16 that says that std.container is pending a rewrite. However it is 2020 now and std.container has still not improved.
>>>
>>> Has any progress made towards the rewrite? Is it at design stage or being developed or has it been forgotten? Is there any timeline for the std.containers rewrite?
>>
>> The latest effort was https://github.com/dlang/druntime/pull/2760, but it stalled as no consensus was reached on how the reference-counting should be done.
>
>
> The technically of the community is both a blessing and a curse. Part of why most things never end up in upstream. std_data_json, dxml, ...?? A perfect solution that never comes.
>
> Dub was bashed so many times now its what we~ all use.
>
> Something is definitely broken in decision making around tools and ecosystem improvement.

That's because nothing that "perfectly aligns" with the vision of Walter/Andrei (Is he relevant anymore to phobos?) will not be accepted into the language.

Which makes a lot of great efforts lost.
June 08, 2020
Hello,
I am the OP (I thought I saved my credentials to my password manager, but apparently not, so I do not have access to that account anymore).

Anyways, after spending more time with D, unfortunately, I have decided to move on to other languages. Apart from this issue, even after being in development for so many years, the editor support is worse than in many newer (or more or less same age) languages like Nim, Haxe etc. It does not support UFCs and many other language features, go to def does not work properly with overloads even though the stdlib is heavily based on overloading etc. The user experience is very poor. :(
June 09, 2020
On Monday, 8 June 2020 at 11:35:16 UTC, exo1 wrote:
> Anyways, after spending more time with D, unfortunately, I have decided to move on to other languages. Apart from this issue, even after being in development for so many years, the editor support is worse than in many newer (or more or less same age) languages like Nim, Haxe etc. It does not support UFCs and many other language features, go to def does not work properly with overloads even though the stdlib is heavily based on overloading etc. The user experience is very poor. :(

Yeah, sadly this may be the weakest part of the D ecosystem. The lack of a up-to-date containers in the standard library usually isn't a real problem, for all the reasons others mentioned above (built in array slices and associative arrays cover most needs, and third-party container libraries are available). However, the IDE support really is quite poor - partly because D is an unusually difficult language to get something like auto-complete working properly for, and partly because most people who really care about IDE support just leave when they see how bad things are on that front, leaving few people who care enough to maintain and improve what we do have.

(For example, I keep meaning to get involved with the IntelliJ-DLanguage project, but I've just been too busy lately to do much beyond submit a few bug reports. The deficiencies are annoying to me, but not critical because the only thing I really *need* from the IDE is the debugger, occasionally.)
« First   ‹ Prev
1 2 3