I downloaded 3ddemo, extracted, built and I get these errors:

logger 2.66.0: building configuration "library"...
\dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16): Error: cannot implicitly convert expression logger of type shared(Logger) to std.historical.logger.core.Logger
\dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21): Error: no property fracSec for type const(SysTime), did you mean std.datetime.systime.SysTime.fracSecs?
\dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(86,27): Error: template instance `std.historical.logger.core.systimeToISOString!(LockingTextWriter)` error instantiating
dmd.exe failed with exit code 1.

This is typical with most of my trials with D... something is always broken all the time and I'm expected to jump through a bunch of hoops to get it to work. File a issue, fix it myself, use a different library, etc. I'm expected to waste my time fixing a problem that really should not exist or should have a high degree of automation to help fix it. I really have better things to do with my time so I won't invest it in D.

This attitude of "It's your problem" is going to kill D.

There is really no incentive for me to use D except for it's language features... everything else it does, besides performance, is shit compared to what most other languages do. Really, D wins on very few metrics but the D fanboys will only focus on those.


If D wants to survive it better get people willing to help it, making their lives more difficult when there are far better options out there will only starve D of what it needs(investing). All those that think D is just fine, you are cutting your own throats... Eventually D will become defunct and you'll have to move on. Might be 10 years, 20 years, 30 years... but when Walter and Andrew are done with D in a few years there will be no one who will keep it alive(maybe a fork will occur but doubtful it would get anywhere).

On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> I downloaded 3ddemo, extracted, built and I get these errors:
>
...
>
> This is typical with most of my trials with D... something is always broken all the time and I'm expected to jump through a bunch of hoops to get it to work. File a issue, fix it myself, use a different library, etc. I'm expected to waste my time fixing a problem that really should not exist or should have a high degree of automation to help fix it. I really have better things to do with my time so I won't invest it in D.
>

Are you talking about this?

https://github.com/clinei/3ddemo

which hasn't been updated since February 2016?

On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> There is really no incentive for me to use D except for it's language features... everything else it does, besides performance, is shit compared to what most other languages do. Really, D wins on very few metrics but the D fanboys will only focus on those.
>
>
> If D wants to survive it better get people willing to help it, making their lives more difficult when there are far better options out there will only starve D of what it needs(investing). All those that think D is just fine, you are cutting your own throats... Eventually D will become defunct and you'll have to move on. Might be 10 years, 20 years, 30 years... but when Walter and Andrew are done with D in a few years there will be no one who will keep it alive(maybe a fork will occur but doubtful it would get anywhere).

If you don't want to use D, then don't use D. No one is holding a gun to your head.

It seems to me like what D needs, right now, is people who are willing to roll up their sleeves and get to work when they see something that needs fixing. If that's something you're either unable or unwilling to do, for whatever reason, then D probably isn't a good choice for you right now. And that's ok. We all have our own goals and priorities, and no single programming language is going to be a perfect fit for everybody.

On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> I downloaded 3ddemo, extracted, built and I get these errors:
>
> logger 2.66.0: building configuration "library"...
> \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16): Error: cannot implicitly convert expression logger of type shared(Logger) to std.historical.logger.core.Logger
> \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21): Error: no property fracSec for type const(SysTime), did you mean std.datetime.systime.SysTime.fracSecs?
> \dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(86,27): Error: template instance `std.historical.logger.core.systimeToISOString!(LockingTextWriter)` error instantiating
> dmd.exe failed with exit code 1.
>
> [...]

Isn't that the historical branch? Well then of course it mightn't work due to advancements in the std lib. Why aren't you using std.experimental.logger?

If D is so "shit", why not use another language? Most things work fine if you aren't grappling to old libraries and using that clutch at straws that D is "dying".

On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> > I downloaded 3ddemo, extracted, built and I get these errors:
> ...
>
> > This is typical with most of my trials with D... something is always broken all the time and I'm expected to jump through a bunch of hoops to get it to work. File a issue, fix it myself, use a different library, etc. I'm expected to waste my time fixing a problem that really should not exist or should have a high degree of automation to help fix it. I really have better things to do with my time so I won't invest it in D.
>
> Are you talking about this?
>
> https://github.com/clinei/3ddemo
>
> which hasn't been updated since February 2016?

This is part of why it's sometimes been discussed that we need a way to indicate which dub packages are currently maintained and work. A package updated last in February of 2016 may very well still work today with the latest compiler, or it may fail to compile as happens here. It depends on what the code is doing, what has changed in D since the last update, and how up-to-date the code really was when it was last updated (e.g. if it was ignoring deprecation warnings rather than fixing them, which I think was the case here).

D is very usable as it is, and there are a number of great packages on dub, but anything that isn't maintained will probably break eventually, even if fixing it would likely be a quick fix. And if it isn't obvious whether a package is maintained or not, it can be very frustrating when someone tries to use it, thinking that it's usable when it isn't really.

I think that it's a bit much to ditch D over a particular package on dub not working, but it is a real problem.

- Jonathan M Davis

On Tuesday, September 4, 2018 7:54:49 PM MDT Dylan Graham via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> > I downloaded 3ddemo, extracted, built and I get these errors:
> >
> > logger 2.66.0: building configuration "library"... \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(1717,16) : Error: cannot implicitly convert expression logger of type shared(Logger) to std.historical.logger.core.Logger \dub\packages\logger-2.66.0\logger\std\historical\logger\core.d(261,21) : Error: no property fracSec for type const(SysTime), did you mean std.datetime.systime.SysTime.fracSecs? \dub\packages\logger-2.66.0\logger\std\historical\logger\filelogger.d(8 6,27): Error: template instance `std.historical.logger.core.systimeToISOString!(LockingTextWriter)` error instantiating dmd.exe failed with exit code 1.
> >
> > [...]
>
> Isn't that the historical branch? Well then of course it mightn't work due to advancements in the std lib. Why aren't you using std.experimental.logger?
>
> If D is so "shit", why not use another language? Most things work fine if you aren't grappling to old libraries and using that clutch at straws that D is "dying".

If I understand correctly, those errors are from trying to simply use a package from code.dlang.org. The code errors are not his. They're a result of the package he's trying to use not being maintained, which very much does suck, though it's going to be a problem with most any language to one degree or another. I think that he's overreacting, but he is pointing out a real problem that has been discussed before. We need to find a way to improve code.dlang.org so that it's clearer whether a package is maintained and working or whether it's been abandoned. For all I know, the folks working on code.dlang.org already have plans for a way to improve that, but they're busy people, and progress isn't always fast - especially when it's a quality of life thing and not a technical issue that has to be fixed for things to work.

- Jonathan M Davis

On Wednesday, 5 September 2018 at 02:10:27 UTC, Jonathan M Davis wrote:
> [...]

Sure, yeah, but if you're using a package that hasn't been maintained in 2-3 years you need to take whether it will work with a grain of salt anyway.

On Tuesday, September 4, 2018 8:37:16 PM MDT Dylan Graham via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 02:10:27 UTC, Jonathan M Davis
>
> wrote:
> > [...]
>
> Sure, yeah, but if you're using a package that hasn't been maintained in 2-3 years you need to take whether it will work with a grain of salt anyway.

Definitely, but plenty of folks seem to eroneously assume that everything on code.dlang.org works, and unless you're actively thinking about the possibility that something there is unmaintained, you're probably not going to notice that it hasn't been updated in years. And sadly, even if a package was updated a few months ago, it could still be broken. So, the date that it was last updated isn't always a good measure of whether it works, though the older the date is, the more likely it is that the package is broken.

I don't actually think that this is a huge issue, but I do think that past discussions on the topic have made it fairly clear that we need to improve code.dlang.org with regards to making it clearer which packages are actively maintained and generally considered to be solid vs those which are unmaintained and/or in an alpha state. Stuff like the package's rating and how old the most recent version is definitely help, but more could (and arguably should) be done. However, as with many things around here, even if we agree that something should be done, that doesn't mean that it's actually going to get done soon - especially if it's something that's more likely to cause pain to newcomers than longtime users.

- Jonathan M Davis

On Wednesday, 5 September 2018 at 01:58:50 UTC, Jonathan M Davis wrote:
> On Tuesday, September 4, 2018 7:18:17 PM MDT James Blachly via Digitalmars-d wrote:
>> [...]
>
> This is part of why it's sometimes been discussed that we need a way to indicate which dub packages are currently maintained and work. A package updated last in February of 2016 may very well still work today with the latest compiler, or it may fail to compile as happens here. It depends on what the code is doing, what has changed in D since the last update, and how up-to-date the code really was when it was last updated (e.g. if it was ignoring deprecation warnings rather than fixing them, which I think was the case here).
>
> [...]

Wouldn´t be interesting to specify the compiler version on dub.json?
(I think ruby uses this idea)

On Wed, Sep 05, 2018 at 01:18:17AM +0000, James Blachly via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 00:49:36 UTC, Everlast wrote:
> > I downloaded 3ddemo, extracted, built and I get these errors:
> > 
> ...
[...]
> Are you talking about this?
> 
> https://github.com/clinei/3ddemo
> 
> which hasn't been updated since February 2016?

To me, this strongly suggests the following idea:
- add *all* dlang.org packages to our current autotester / CI
  infrastructure.
- if a particular (version of a) package builds successfully, log the
  compiler version / git hash / package version to a database and add
  a note to dlang.org that this package built successfully with this
  compiler version.
- if a particular (version of a) package fails to build for whatever
  reason, log the failure and have a bot add a note to dlang.org that
  this package does NOT build with that compiler version.
   - possibly add the package to a blacklist for this compiler version
     so that we don't consume too many resources on outdated packages
     that no longer build.
- periodically update dlang.org (by bot) to indicate the last known
  compiler version that successfully built this package.
- in the search results, give preference to packages that built
  successfully with the latest official release.

This should help clear up these incidents with outdated packages.


T


T

-- 
When solving a problem, take care that you do not become part of the problem.