On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote:
> *whispers* Hey hey you. You want tests? Well here is something you'll like[0]. Oh and check out[1].
>
> [0] http://www.libpng.org/pub/png/pngsuite.html
> [1] http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx@forum.dlang.org

Well done you've written a library to pass some tests. Now fix the bugs that you haven't found yet and scalability issues you aren't aware of...the things that really only spring up when you get 1000+ users thrashing it each week.

In the meantime I'll use D bindings to FreeImage or similar ilk that's gone through the wringer several times over.

Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries.

bye,
lobo

On 8/08/2015 8:05 p.m., lobo wrote:
> On Friday, 7 August 2015 at 04:56:39 UTC, Rikki Cattermole wrote:
>> *whispers* Hey hey you. You want tests? Well here is something you'll
>> like[0]. Oh and check out[1].
>>
>> [0] http://www.libpng.org/pub/png/pngsuite.html
>> [1] http://forum.dlang.org/post/zxbexpwmirzdkewhqjyx@forum.dlang.org
>
> Well done you've written a library to pass some tests. Now fix the bugs
> that you haven't found yet and scalability issues you aren't aware
> of...the things that really only spring up when you get 1000+ users
> thrashing it each week.
>
> In the meantime I'll use D bindings to FreeImage or similar ilk that's
> gone through the wringer several times over.
>
> Sorry I don't mean to sound harsh but that's the reality I'm in right
> now pushing D on teams in my workplace. It would be much simpler if
> there were quality (idiomatic) D interfaces to existing quality C/C++
> libraries.
>
> bye,
> lobo

I've been saying from the beginning that we need both D implementation of some simpler formats such as PNG AND bindings + implementation for e.g. FreeImage.

I have NEVER said that we should only use D code. Only an out of the box experience must not require external code.

I wish people understood that I'm truly trying to meet people half way. That I'm not advocating NIH syndrome in any form and that other libraries can benefit us. If used the right way.

On Saturday, 8 August 2015 at 08:05:27 UTC, lobo wrote:
> Sorry I don't mean to sound harsh but that's the reality I'm in right now pushing D on teams in my workplace. It would be much simpler if there were quality (idiomatic) D interfaces to existing quality C/C++ libraries.

Have you looked at  http://code.dlang.org/packages/gfm%3Afreeimage ?

On Friday, 7 August 2015 at 20:24:54 UTC, jmh530 wrote:
> On Friday, 7 August 2015 at 17:40:16 UTC, deadalnix wrote:
>> [...]
>
> I wouldn't think what you're saying is controversial...just a lot of work to do well.
>
> [...]

+2000

On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:
>>
>> On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:
>>>>
>>>>
>>>> On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>>
>>>>>
>>>>> On 5/08/2015 6:59 a.m., develop32 wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> D is really cool and makes a good candidate for developing a game.
>>>>>>> Are
>>>>>>> there any guys out there using D for indie games?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not an indie game, but Remedy is making Quantum Break using D.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Got a source for that? As I can't find it.
>>>>
>>>>
>>>>
>>>> Hi. I dunnit, and I did a talk about it at dconf2013.
>>>
>>>
>>>
>>> I knew you were involved with them back then. I was more interested in anything that happened after that.
>>
>>
>> It took a lot longer for us to get the compiler to a sufficiently
>> stable state that we were able to build reliably than we'd liked. In
>> the mean time, code pegged for D was forced to be written in C, so a
>> lot of D code ended out being C code on account of 'couldn't wait'.
>> When I left, there were a couple of critical systems running in D, and
>> a few toolchain issues left to work out (Windows DLL's + GC). It was
>> left with Ethan who occasionally appears here.
>> I'm not sure where it went after that. There was much enthusiasm among
>> the team, but the toolchain progressed slower than we could afford,
>> and we just had to get on with it in some cases. Hopefully there's
>> still some D code in there, and (if the problems were fixed!) there's
>> no good reason why it wouldn't have scaled out from where I left it.
>
>
> Yeah I hope it had. Although would be nice to hear from Remedy what they
> currently use / think of D.
> I kinda hoped that they had released e.g. a blog post about it, which they
> haven't.

Our experience wasn't really positive. Can't/don't-want-to write a
blog post about that.
Trust me, we were very enthusiastic to stand at GDC and give a lecture
about our experience, but it didn't really go according to plan,
mostly blocked by trivial shit that's been known problems for at least
as long as I've been around here.
It's not so much language problems, it's tooling problems. It's the
most important and perhaps most neglected aspect of the D ecosystem.

1. DMD has unsatisfactory codegen for anything other than debug builds.
2. DMD generates x87 code, and uses real everywhere. We can't be
generating new x87+real instructions in 2015. It's deprecated
hardware!
2. LDC has a lot more bugs than DMD (which still has quite a few
bugs), and the Windows build is new and even more immature still.
3. LDC has no debuginfo. **biggest practical issue by far!**
4. LDC/GDC are always a few versions behind DMD. This creates an
awkward/almost-impossible situation when you rely on DMD to build
debug code, and LDC to build releasable code. Depending on 2 flaky
compilers is even less fun than one.
5. DLL's were really flakey at the time, I'm not sure how they are
now, but I'm concerned they may not be much better.
6. Shared druntime; we were loading D code from DLL's, lots of them.
It's not really reasonable for each DLL to have it's own druntime
instance, they need to share one provided by the host app.
7. D binaries are *gigantic*, I don't know why. D seems to link the
world, and I'm certain that most of the crap that's linked is never
referenced or executed... it just makes gigantic binaries for some
reason, even with line-for-line translations of C/C++ code. That's not
real good on games consoles where icache is king.


I tried to use D in my current workplace on 3 occasions now, and ran
into a different set of problems.
In the first attempt I tried to write a simple vibe.d webserver app,
but it kept crashing randomly when I was using the API's exactly as
intended (apparently a client was posting `/n` instead of `/r/n`, or
maybe the inverse of that, and it didn't like it). The IDE/debugging
situation is basically impossible; vibe.d throws exceptions all over
the place, with no really good tools for debugging this sort of thing.
My colleagues freaked out and thought I was crazy, and my credibility
was diminished.

In my second attempt, progress was interrupted by some ICE's, linking with some C++ code caused various problems.

I investigated making another attempt to use D where we have some web front-end code that's built using Emscripten. D would have been perfect for this job, but LDC can't target Emscripten and/or NaCl. I don't see that coming along any time soon. I briefly looked at trying to make an Emscripten build of LDC, but it requires probably weeks worth of research and expert knowledge to approach it.

A final recent attempt was basically a non-starter on account of no Qt bindings that work &&/|| are up to date.

I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but it's *possible* to get my work done... and that's more important than literally anything else.

I'm getting pretty close to calling it a day. Is 6 years enough time
to repeatedly prove to myself that I'm chasing a fantasy?
People keep talking about Rust, I'm thinking of giving it a shot.

I think D needs a budget, and paid programmers employed to do boring
shit that makes the whole thing more stable and robust. Mozilla seems
to have this(?)
D seems to consistently offer 95% solutions to problems. 95% is not a
solution, it's just another problem.

Oops, I ranted. Sorry! :)

On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
> On 6 August 2015 at 21:46, Rikki Cattermole via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 6/08/2015 11:30 p.m., Manu via Digitalmars-d wrote:
>>>
>>> On 6 August 2015 at 21:23, Rikki Cattermole via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On 6/08/2015 11:18 p.m., Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> On 5 August 2015 at 05:13, Rikki Cattermole via Digitalmars-d
>>>>> <digitalmars-d@puremagic.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 5/08/2015 6:59 a.m., develop32 wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> D is really cool and makes a good candidate for developing a game.
>>>>>>>> Are
>>>>>>>> there any guys out there using D for indie games?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Not an indie game, but Remedy is making Quantum Break using D.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Got a source for that? As I can't find it.
>>>>>
>>>>>
>>>>>
>>>>> Hi. I dunnit, and I did a talk about it at dconf2013.
>>>>
>>>>
>>>>
>>>> I knew you were involved with them back then. I was more interested in
>>>> anything that happened after that.
>>>
>>>
>>> It took a lot longer for us to get the compiler to a sufficiently
>>> stable state that we were able to build reliably than we'd liked. In
>>> the mean time, code pegged for D was forced to be written in C, so a
>>> lot of D code ended out being C code on account of 'couldn't wait'.
>>> When I left, there were a couple of critical systems running in D, and
>>> a few toolchain issues left to work out (Windows DLL's + GC). It was
>>> left with Ethan who occasionally appears here.
>>> I'm not sure where it went after that. There was much enthusiasm among
>>> the team, but the toolchain progressed slower than we could afford,
>>> and we just had to get on with it in some cases. Hopefully there's
>>> still some D code in there, and (if the problems were fixed!) there's
>>> no good reason why it wouldn't have scaled out from where I left it.
>>
>>
>> Yeah I hope it had. Although would be nice to hear from Remedy what they
>> currently use / think of D.
>> I kinda hoped that they had released e.g. a blog post about it, which they
>> haven't.
>
> Our experience wasn't really positive. Can't/don't-want-to write a
> blog post about that.
> Trust me, we were very enthusiastic to stand at GDC and give a lecture
> about our experience, but it didn't really go according to plan,
> mostly blocked by trivial shit that's been known problems for at least
> as long as I've been around here.
> It's not so much language problems, it's tooling problems. It's the
> most important and perhaps most neglected aspect of the D ecosystem.
>
> 1. DMD has unsatisfactory codegen for anything other than debug builds.
> 2. DMD generates x87 code, and uses real everywhere. We can't be
> generating new x87+real instructions in 2015. It's deprecated
> hardware!
> 2. LDC has a lot more bugs than DMD (which still has quite a few
> bugs), and the Windows build is new and even more immature still.
> 3. LDC has no debuginfo. **biggest practical issue by far!**
> 4. LDC/GDC are always a few versions behind DMD. This creates an
> awkward/almost-impossible situation when you rely on DMD to build
> debug code, and LDC to build releasable code. Depending on 2 flaky
> compilers is even less fun than one.
> 5. DLL's were really flakey at the time, I'm not sure how they are
> now, but I'm concerned they may not be much better.
> 6. Shared druntime; we were loading D code from DLL's, lots of them.
> It's not really reasonable for each DLL to have it's own druntime
> instance, they need to share one provided by the host app.
> 7. D binaries are *gigantic*, I don't know why. D seems to link the
> world, and I'm certain that most of the crap that's linked is never
> referenced or executed... it just makes gigantic binaries for some
> reason, even with line-for-line translations of C/C++ code. That's not
> real good on games consoles where icache is king.
>
>
> I tried to use D in my current workplace on 3 occasions now, and ran
> into a different set of problems.
> In the first attempt I tried to write a simple vibe.d webserver app,
> but it kept crashing randomly when I was using the API's exactly as
> intended (apparently a client was posting `/n` instead of `/r/n`, or
> maybe the inverse of that, and it didn't like it). The IDE/debugging
> situation is basically impossible; vibe.d throws exceptions all over
> the place, with no really good tools for debugging this sort of thing.
> My colleagues freaked out and thought I was crazy, and my credibility
> was diminished.
>
> In my second attempt, progress was interrupted by some ICE's, linking
> with some C++ code caused various problems.
>
> I investigated making another attempt to use D where we have some web
> front-end code that's built using Emscripten. D would have been
> perfect for this job, but LDC can't target Emscripten and/or NaCl. I
> don't see that coming along any time soon. I briefly looked at trying
> to make an Emscripten build of LDC, but it requires probably weeks
> worth of research and expert knowledge to approach it.
>
> A final recent attempt was basically a non-starter on account of no Qt
> bindings that work &&/|| are up to date.
>
> I'm using C++11 now, it's horrible. Let me repeat, it's HORRIBLE, but
> it's *possible* to get my work done... and that's more important than
> literally anything else.
>
> I'm getting pretty close to calling it a day. Is 6 years enough time
> to repeatedly prove to myself that I'm chasing a fantasy?
> People keep talking about Rust, I'm thinking of giving it a shot.
>
> I think D needs a budget, and paid programmers employed to do boring
> shit that makes the whole thing more stable and robust. Mozilla seems
> to have this(?)
> D seems to consistently offer 95% solutions to problems. 95% is not a
> solution, it's just another problem.
>
> Oops, I ranted. Sorry! :)

Don't worry about it!
But I see your point. All we can do is truck on.

You will enjoy my latest blog post I think[0].
I reiterate one thing, if it's hard, it's probably wrong. So, lets make things easy. Build a wide range a libraries to make certain programs easy to write.

Something I'd like to say is that I do really appreciate you and your work. If I could I would love to learn from you directly. I cannot give a higher respect or appreciation then that.
Even though it is hard for you to still be here, I hope you do continue to help D grow. This is a good community, we just need time before real adoption. E.g. we are only just now starting to unify projects.

[0] http://cattermole.co.nz/blog/uncategorized/where-goes-game-development-in-d/

On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
> ...

This pretty much hit the nail on the head on why dmd needs deprecated.

I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned.

dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.

On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:
> 1. DMD has unsatisfactory codegen for anything other than debug builds.

Do you mean the codegen is slower? But consider that the bottleneck in most programs is a small section of code. Taking a good look at the generated code for that and comparing with another compiler can often hint at an easy improvement to dmd that can address that bottleneck.

But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time.


> 2. DMD generates x87 code, and uses real everywhere.

Less so now than it used to. For float and double, it uses SIMD.

> We can't be
> generating new x87+real instructions in 2015. It's deprecated
> hardware!

x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. Why was it a problem for you?


> 2. LDC has a lot more bugs than DMD (which still has quite a few
> bugs), and the Windows build is new and even more immature still.
> 3. LDC has no debuginfo. **biggest practical issue by far!**
> 4. LDC/GDC are always a few versions behind DMD. This creates an
> awkward/almost-impossible situation when you rely on DMD to build
> debug code, and LDC to build releasable code. Depending on 2 flaky
> compilers is even less fun than one.
> 5. DLL's were really flakey at the time, I'm not sure how they are
> now, but I'm concerned they may not be much better.
> 6. Shared druntime; we were loading D code from DLL's, lots of them.
> It's not really reasonable for each DLL to have it's own druntime
> instance, they need to share one provided by the host app.

I agree, and now we ship a Phobos DLL, resolving that issue.

> 7. D binaries are *gigantic*, I don't know why. D seems to link the
> world, and I'm certain that most of the crap that's linked is never
> referenced or executed... it just makes gigantic binaries for some
> reason, even with line-for-line translations of C/C++ code. That's not
> real good on games consoles where icache is king.

Yes, that's an ongoing problem. I need to spend some time on that one.


> I tried to use D in my current workplace on 3 occasions now, and ran
> into a different set of problems.
> In the first attempt I tried to write a simple vibe.d webserver app,
> but it kept crashing randomly when I was using the API's exactly as
> intended (apparently a client was posting `/n` instead of `/r/n`, or
> maybe the inverse of that, and it didn't like it).

Were these bugs reported?


> In my second attempt, progress was interrupted by some ICE's, linking
> with some C++ code caused various problems.

ICE's in what? What problems?


> A final recent attempt was basically a non-starter on account of no Qt
> bindings that work &&/|| are up to date.

Bindings aren't too hard to update.


> I'm getting pretty close to calling it a day. Is 6 years enough time
> to repeatedly prove to myself that I'm chasing a fantasy?
> People keep talking about Rust, I'm thinking of giving it a shot.
>
> I think D needs a budget, and paid programmers employed to do boring
> shit that makes the whole thing more stable and robust. Mozilla seems
> to have this(?)
> D seems to consistently offer 95% solutions to problems. 95% is not a
> solution, it's just another problem.
>
> Oops, I ranted. Sorry! :)

I think what stalled Remedy's use of D is you left Remedy. Note that while you were there I went to Finland largely at my own expense to help make it work for Remedy. After you left, there wasn't much interest from Remedy.

I note that I rarely know just what is blocking you. For example, you say above you got some ICEs. What ICEs? We cannot fix bugs we don't know about. I would also very much appreciate if you would pitch in to help with things that are blocking you, like updated Qt bindings. Generally, people around here tend to contribute fixes for things that personally interest or block them. Priorities for you aren't priorities for others.

D doesn't have a community so large that you can sit back and assume many others will run into the same issues you have and will fix them. You have to be more proactive.

Looking at open bugzilla issues you've commented on:

https://issues.dlang.org/show_bug.cgi?id=5227
https://issues.dlang.org/show_bug.cgi?id=6343
https://issues.dlang.org/show_bug.cgi?id=8845
https://issues.dlang.org/show_bug.cgi?id=9065
https://issues.dlang.org/show_bug.cgi?id=9137
https://issues.dlang.org/show_bug.cgi?id=10203
https://issues.dlang.org/show_bug.cgi?id=10959
https://issues.dlang.org/show_bug.cgi?id=11541
https://issues.dlang.org/show_bug.cgi?id=12440
https://issues.dlang.org/show_bug.cgi?id=13265
https://issues.dlang.org/show_bug.cgi?id=14260

That's it. None of them seem to be ones you brought up in your post. To get attention for issues that are blocking you you absolutely have to file bugzilla reports. That doesn't guarantee they will be fixed, but if you do not file them, it DOES guarantee that they will NOT be addressed, and you'll get frustrated.

On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
> On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
>> ...
>
> This pretty much hit the nail on the head on why dmd needs deprecated.
>
> I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I don't care if it works on windows, it produces code slower than interpreted lua. Exactly what use is that? It may as well not work on windows at all as far as release builds are concerned.
>
> dmd not being deprecated continues the cycle of gdc/ldc lagging versions behind and being understaffed in manpower.

I think another point to look at is how far gdc and ldc have come while still having so few people working on them. Clearly they are able to get more done faster because they can leverage the work of the llvm and gcc devs. Seems silly that the majority of our talent is focused on dmd when it is the slowest of the bunch. D's "not made here" syndrome strikes again!

Also I really wish we had 1 main editor that was "THE" D editor. Something that was officially maintained and packaged with the rest of D. VisualD is cool, but not cross platform. monoD is nice, but no windows debugging support. DDT is also nice, it says it can do debugging in windows, but I was never been able to get it to work. They all have problems. If I had to vote, I would vote for monoD or DDT as they are both the closest to being complete solutions. But one really needs to be the focus and packaged with D, make it complete and let the others die.

D debugging is in a laughable state. It really sucks and it seems to not be a concern at all by the core D people. That alone is a huge problem. If only we could get a cross platform D debugger that just worked and was officially maintained.

Again tooling is D's biggest problem.

Just my 2c

On 9 August 2015 at 07:31, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:
>
>> 1. DMD has unsatisfactory codegen for anything other than debug builds.
>>
>
> Do you mean the codegen is slower? But consider that the bottleneck in most programs is a small section of code. Taking a good look at the generated code for that and comparing with another compiler can often hint at an easy improvement to dmd that can address that bottleneck.
>
> But waiting for someone else to discover the same thing on some other piece of code means you'll be waiting a long time.
>
>
Sometimes just using the wrong CPU can have adverse effects:

https://issues.dlang.org/show_bug.cgi?id=5100



>
> 2. DMD generates x87 code, and uses real everywhere.
>>
>
> Less so now than it used to. For float and double, it uses SIMD.
>
> We can't be
>> generating new x87+real instructions in 2015. It's deprecated hardware!
>>
>
> x87 works on every x86 CPU, and I doubt it will ever go away, deprecated or not. Why was it a problem for you?
>
>
I know that at least for the benefit of std.math, we should allow any precision without expensive casting to and from real, which has been found to be a performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).

Iain.