www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is everything alright?

reply GL <gleb.tsk gmail.com> writes:
Good afternoon,
is everything okay with the development? For example, 
https://code.dlang.org/packages/libasync. Only two years have 
passed, but this package is no longer being assembled.
Is it good?
In other words, it is still difficult to recommend D for use.
How sad it is...
Jul 19 2022
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development?


Yes


 For example, https://code.dlang.org/packages/libasync. Only two 
 years have passed, but this package is no longer being 
 assembled.
 Is it good?


You should ask the developers of the package. There should be a 
link to the repo at the link you posted.


 In other words, it is still difficult to recommend D for use.
 How sad it is...


That escalated quickly
Jul 19 2022
parent reply GL <gleb.tsk gmail.com> writes:
On Tuesday, 19 July 2022 at 11:52:53 UTC, bachmeier wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development?


 Yes


I wish I could be so sure. This means that most of the packages 
in "dlang.org/packages" are useless. "Libasync" mentioned earlier 
has over 15,000 lines, what a great job! And it's practically all 
rubbish. Only because someone decided that the enforceEx symbol 
previously defined in the STANDARD library was not elegant 
enough. In the *standard*, *core* library, Carl!
Something is rotten in the state of Denmark...


 For example, https://code.dlang.org/packages/libasync. Only 
 two years have passed, but this package is no longer being 
 assembled.
 Is it good?


 You should ask the developers of the package. There should be a 
 link to the repo at the link you posted.


It is known, many repositories (such as the Linux package 
repositories) are known to use a mechanism for automatic 
rebuilding in a clean environment and notification, such as 
"repocop / hasher".
Is there anything similar here?
How does the author know that there are problems (how many 
authors read reports on packages published many years ago)?
Jul 19 2022
next sibling parent bachmeier <no spam.net> writes:
On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

 On Tuesday, 19 July 2022 at 11:52:53 UTC, bachmeier wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development?


 Yes


 I wish I could be so sure. This means that most of the packages 
 in "dlang.org/packages" are useless. "Libasync" mentioned 
 earlier has over 15,000 lines, what a great job! And it's 
 practically all rubbish. Only because someone decided that the 
 enforceEx symbol previously defined in the STANDARD library was 
 not elegant enough. In the *standard*, *core* library, Carl!
 Something is rotten in the state of Denmark...


You are talking about a third-party package. Do you contact the 
Rust core team with issues about arbitrary packages written in 
Rust? Do you tell them that Rust is a lost cause because someone 
wrote a package that's not properly maintained using their 
language?

I will repeat my earlier comment: Contact the developers of the 
package. For your convenience, this is the link

https://github.com/etcimon/libasync
Jul 20 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

 I wish I could be so sure. This means that most of the packages 
 in "dlang.org/packages" are useless. "Libasync" mentioned 
 earlier has over 15,000 lines, what a great job!


I don't know anything about this library, but any library that 
has not reached v1.0 yet should be considered as experimental and 
unsupported…
Jul 20 2022
parent GL <gleb.tsk gmail.com> writes:
On Wednesday, 20 July 2022 at 16:16:43 UTC, Ola Fosheim Grøstad 
wrote:

 On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

 I wish I could be so sure. This means that most of the 
 packages in "dlang.org/packages" are useless. "Libasync" 
 mentioned earlier has over 15,000 lines, what a great job!


 I don't know anything about this library, but any library that 
 has not reached v1.0 yet should be considered as experimental 
 and unsupported…


Version number? Yah?
In other words, when working in D, it is impossible to rely on 
any (open) code.

Or you need constant assistance from the authors, which is not 
realistic.

Or you have to constantly reinvent your own bicycles and 
substitute crutches. Tertium non datur. No "batteries included": 
it is simply impossible to rely on the development of useful code 
by the community, the obsolescence of the compiler requires 
constant and continuous rewriting of the "whole World".

PS: It looks like the author of the mentioned library is not 
responding or has lost interest. Assembly with a modern compiler 
requires a very deep analysis of the code, since cast errors 
occur. So, long live for own "bicycles and crutches". Wonderful.
Jul 22 2022
prev sibling parent Martin B <martin.brzenska googlemail.com> writes:
On Wednesday, 20 July 2022 at 05:56:52 UTC, GL wrote:

[...]automatic rebuilding in a clean environment and 
notification[...]


actually, i find this a good idea. Packages are getting 
registered on code.dlang.org without any qualification (AFAIK). 
Maybe it would make sense to develop some automated challenge 
that a package/project must pass in order to get listed on 
code.dlang.org and after that periodical checks with a grace time 
after which the project will be flagged as unmaintained and 
eventually removed (or hidden by default with opt-in to see and 
use unmaintained packages)
Jul 22 2022
prev sibling next sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


Maybe the author just need help in development from community? 
Many libraries like libasync and memutils are used as 
dependencies in other projects.
Jul 21 2022
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


hottake: its possible to use d without dub
Jul 22 2022
next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jul 22, 2022 at 07:30:46PM +0000, monkyyy via Digitalmars-d wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example,
 https://code.dlang.org/packages/libasync. Only two years have passed,
 but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


 
 hottake: its possible to use d without dub


I regularly use D but hardly ever use dub. The only time I've used it is
just using a dummy project to pull in vibe.d dependencies; the actual
build is handled by SCons outside the dub project subdirectory.


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do
criticize him, you'll be a mile away and he won't have his shoes.
Jul 22 2022
prev sibling parent reply GL <gleb.tsk gmail.com> writes:
On Friday, 22 July 2022 at 19:30:46 UTC, monkyyy wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


 hottake: its possible to use d without dub


What's the dub here? My "cry from the heart" was about the 
impossibility of recommending D for anything in the slightest 
serious. Because of compiler development policy.
Jul 24 2022
next sibling parent Tejas <notrealemail gmail.com> writes:
On Sunday, 24 July 2022 at 12:54:37 UTC, GL wrote:

 On Friday, 22 July 2022 at 19:30:46 UTC, monkyyy wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


 hottake: its possible to use d without dub


 What's the dub here? My "cry from the heart" was about the 
 impossibility of recommending D for anything in the slightest 
 serious. Because of compiler development policy.


Dub is D's package manager and build system

https://dub.pm/getting_started
Jul 24 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 24 July 2022 at 12:54:37 UTC, GL wrote:

 On Friday, 22 July 2022 at 19:30:46 UTC, monkyyy wrote:

 On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


 hottake: its possible to use d without dub


 What's the dub here? My "cry from the heart" was about the 
 impossibility of recommending D for anything in the slightest 
 serious. Because of compiler development policy.


At this point, you're obviously trolling. You're complaining 
about a third-party package, not compiler development policy. But 
I do agree that - for some reason and with no supporting evidence 
- you repeatedly make the claim that nobody should use D.
Jul 24 2022
parent reply GL <gleb.tsk gmail.com> writes:
 At this point, you're obviously trolling.


Absolutely not!


 You're complaining about a third-party package, not compiler 
 development policy.


The third-party package can not be assembled because of compiler 
changes.
Whereas two years ago ONLY the build was quite successful.

Many C++ library code from 2000 and even 1996 are still assembled 
without any changes.

Python library, *formed* in 1995 -- 2006, was useably up to new 
ages of Python 3 without any problem.

This made it possible to form a large code base.

And in our case, we have unpredictable and catastrophic 
obsolescence of the code within a couple of years or even less. 
Actually, any code can explode unpredictably at any moment. As a 
result of compiler changes. Isn't this the result of policy? 
Doesn't that make serious use in real life impossible when you 
have to use third-party libraries extensively?


 But I do agree that - for some reason and with no supporting 
 evidence - you repeatedly make the claim that nobody should use 
 D.


I never said anything like that. I'm just stating the obvious --- 
such rapid and undetectable code obsolescence is absolutely 
disastrous for the reputation of the compiler and the whole D's  
ecosystem. This is purely a result of politics.
Jul 24 2022
parent Zealot <no2 no.no> writes:
On Monday, 25 July 2022 at 05:56:00 UTC, GL wrote:

 [...]




do you also complain that C++ is unusable because they constantly 
change up their language and standard library?
Dec 03 2022
prev sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 19 July 2022 at 09:18:12 UTC, GL wrote:

 Good afternoon,
 is everything okay with the development? For example, 
 https://code.dlang.org/packages/libasync. Only two years have 
 passed, but this package is no longer being assembled.
 Is it good?
 In other words, it is still difficult to recommend D for use.
 How sad it is...


Anyone is going to fork it for maintenance purposes?
There are several packages that need to be updated.. and many 
others have libasync and memutils as a dependency
Dec 03 2022