On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
> it's almost 8 years now, is D's industry adoption picking up?

Wow, it's more than 20 years now: quote

https://forum.dlang.org/post/nrhhnhocbsamkifkhzrd@forum.dlang.org

"""
Hi Walter,

You had asked me a question that I have been thinking about for a couple years.

Your question from 2009 was, “How can D become adopted at my company?”


*** What makes a language successful? ***

I think Stroustrup’s answer is the best metric I’ve heard:  a language is successful if it is used.

"""

On Saturday, 23 May 2020 at 02:07:45 UTC, mw wrote:
> On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
> Wow, it's more than 20 years now: quote

20 -- I mean since D started.

On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:
> The other decimal package actually looks pretty decent:

For this reason I have started my own extremely simple fixedpoint type:
https://github.com/m3m0ry/fixedpoint
https://code.dlang.org/packages/fixedpoint

For me it would be great, if you use it for a personal project, since I am as well.


As for the decimal package. I am currently trying to get the "rights" to it, so I can fix it.

The problem with decimal types is, that one solution is not enough. There are many possibilities how to achieve it, each of them having its own pros and cons.

On Saturday, 23 May 2020 at 06:57:32 UTC, Jan Hönig wrote:
> For this reason I have started my own extremely simple

I see you have found it :)

On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
>
> And worse, it looks like both packages are no longer maintained by their original owners.
>
> Then I found other people experienced the same difficulties, and started to re-invent those wheels, and the new packages are in 0.0.x stage with limited functionalities.
>
> I think we are wasting our community effort here. I'm wondering
>

Because this, I forked two small packages and get it under my wing, with the self-compromise that at least I will keep it working on future versions of D. However, I published they with different names and changing the module name. Something that should be totally unnecessary.

And there are many packages with the same problem on the wild.

On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
> Well, fork and fix is ok for personal project; but for the company, they will certainly say: why not choose a mature language with mature libraries? why not just use Java / Python / C++? why should we spend time fixing the libraries instead of getting our (functionality) work done?

If the library was in a complete and stable state when original the maintainer left, picking up it's maintenance is not that much of a trouble, assuming you only want to keep it compiling and to fix the most critical bugs. Even for a lone programmer it's worth considering, and more so for a company with many programmers.

This is because regressions due to library development is the main way the library can break code using it. If the development stops, so do the regressions, and code using it tends to keep working. The only problems left are:
1. breakage due to language updates
2. old bugs that the user has not happened to trigger.

Point one is much less work than dealing with regressions, and point two can usually be worked around, if fixing the library is too hard: You didn't trigger the feature before, so you can usually continue to avoid the usage that triggers the bug.

On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
> Because this, I forked two small packages and get it under my wing, with the self-compromise that at least I will keep it working on future versions of D. However, I published they with different names and changing the module name. Something that should be totally unnecessary.
>
> And there are many packages with the same problem on the wild.


Right, people forked & fixed, but the fix cannot be contributed back to the D community.

Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches.

So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems.

Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.

On Saturday, 23 May 2020 at 10:23:09 UTC, Dukc wrote:
> On Saturday, 23 May 2020 at 02:04:01 UTC, mw wrote:
>> Well, fork and fix is ok for personal project; but for the company, they will certainly say: why not choose a mature language with mature libraries? why not just use Java / Python / C++? why should we spend time fixing the libraries instead of getting our (functionality) work done?
>
> If the library was in a complete and stable state when original the maintainer left, picking up it's maintenance is not that much of a trouble, assuming you only want to keep it compiling and to fix the most critical bugs. Even for a lone programmer it's worth considering, and more so for a company with many programmers.

This is majority of the case we care about, i.e. fix the bug found in well-used unmaintained  packages.


But for industry usage, there is another side of the story, i.e accountability & company politics. The managers who can make decisions (together with the consequent responsibility) have to think about the worst scenario: what if the project missed the deadline? or even fail? Will s/he *bet* his/her job security or even career on a new language / library? Most managers sure won't. That's why companies always want to use *mature* language & libraries:

1) the project schedule can be more reliably estimated (without wasting extra time, detour to fix libraries bugs)

2) if the project delayed, or failed, at least nobody in the company can blame him/her choosed a new language & new libraries that caused the failure.

On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:
> On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
>> Because this, I forked two small packages and get it under my wing, with the self-compromise that at least I will keep it working on future versions of D. However, I published they with different names and changing the module name. Something that should be totally unnecessary.
>>
>> And there are many packages with the same problem on the wild.
>
>
> Right, people forked & fixed, but the fix cannot be contributed back to the D community.
>
> Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches.
>
> So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems.
>
> Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.

How about putting every packages under dlang-community under a repo maintained by community so anyone else can accept pull request.

If anyone else starts another decimal package, it'll also end up the same way most likely.

It's about time we have packages regarded as core with the community in charge...so we can direct contributions to them. Every fix gets submitted there...

On Saturday, 23 May 2020 at 17:46:42 UTC, aberba wrote:
> On Saturday, 23 May 2020 at 17:10:27 UTC, mw wrote:
>> On Saturday, 23 May 2020 at 07:27:50 UTC, Luis wrote:
>>> Because this, I forked two small packages and get it under my wing, with the self-compromise that at least I will keep it working on future versions of D. However, I published they with different names and changing the module name. Something that should be totally unnecessary.
>>>
>>> And there are many packages with the same problem on the wild.
>>
>>
>> Right, people forked & fixed, but the fix cannot be contributed back to the D community.
>>
>> Other users are still getting the original buggy version from dub, and don't have an easy way to find new patches.
>>
>> So the main blocker is to get the write permission (of the unmaintained packages) of the dub system, this will solve lots of these problems.
>>
>> Or we should setup a new policy that any new dub packages should give write permission to dlang-community by default.
>
> How about putting every packages under dlang-community under a repo maintained by community so anyone else can accept pull request.
>
> If anyone else starts another decimal package, it'll also end up the same way most likely.
>
> It's about time we have packages regarded as core with the community in charge...so we can direct contributions to them. Every fix gets submitted there...

The community here is very week. I've also talked to lack of focus on community building. Every open source endure needs a strong community to make things happen under a collective effort. Until there's official push and dedication to making that happen, we'll also be overruns by things to do.