Walter Bright wrote:
> Andrei posted this on another thread. I felt it deserved its own thread.
> It's very important.
> -----------------------------------------------------------------------------
>
> I go to conferences. Train and consult at large companies. Dozens every
> year, cumulatively thousands of people. I talk about D and ask people
> what it would take for them to use the language. Invariably I hear a
> surprisingly small number of reasons:
>
> * The garbage collector eliminates probably 60% of potential users right
> off.
>
> * Tooling is immature and of poorer quality compared to the competition.
>
> * Safety has holes and bugs.
>
> * Hiring people who know D is a problem.
>
> * Documentation and tutorials are weak.
>
> * There's no web services framework (by this time many folks know of D,
> but of those a shockingly small fraction has even heard of vibe.d). I
> have strongly argued with Sönke to bundle vibe.d with dmd over one year
> ago, and also in this forum. There wasn't enough interest.
>
> * (On Windows) if it doesn't have a compelling Visual Studio plugin, it
> doesn't exist.
>
> * Let's wait for the "herd effect" (corporate support) to start.
>
> * Not enough advantages over the competition to make up for the
> weaknesses above.
>

A note to all on the GC. We have a GSoC project this year for the GC. He is currently working on improving the GC code to allow for multiple GC implementations and bringing in Rainer's Precise GC on-board. Once he has completed the on-boarding he will work on improving the precision of the precise GC.

A precise GC is important as it paves the way for background/generational/concurrent GC algorithms, such as what you find in modern .NET/Java apps. I feel that this will go a *long* towards solving the majority of the complaints about the GC, with the exception of the "never-GC" crowd.

-- 
// Adam Wilson
// import quiet.dlang.dev;

On 6/6/2016 5:19 PM, Brad Roberts via Digitalmars-d wrote:
> This isn't a small problem, don't dismiss it quite that quickly.  Safety as a
> usable subset of D is still pretty non-existent and yet is used as a selling
> point.

I use it regularly.

> The language still has holes -- I don't have bug report numbers, but
> others have reported them in the past, some closed some not.  At the library
> level things are far worse.  I've yet to be able to write any interesting apps
> with an @safe main.

It's harder to make your program compile with @safe. That is not a bug in the language.

On 6/6/2016 5:19 PM, Brad Roberts via Digitalmars-d wrote:
> Safety as a
> usable subset of D is still pretty non-existent and yet is used as a selling
> point.  The language still has holes -- I don't have bug report numbers, but
> others have reported them in the past, some closed some not.  At the library
> level things are far worse.  I've yet to be able to write any interesting apps
> with an @safe main.

Without knowing any details of why your app wouldn't compile as @safe, there's nothing useful nor actionable in the complaint.

There also is a conflation of two issues in the complaint - compiling programs that are unsafe despite being marked @safe, and the compiler complaining about unsafe code in code you'd like to be marked @safe. Which is it?

On 6/6/2016 10:25 PM, Walter Bright via Digitalmars-d wrote:
> On 6/6/2016 5:19 PM, Brad Roberts via Digitalmars-d wrote:
>> Safety as a
>> usable subset of D is still pretty non-existent and yet is used as a
>> selling
>> point.  The language still has holes -- I don't have bug report
>> numbers, but
>> others have reported them in the past, some closed some not.  At the
>> library
>> level things are far worse.  I've yet to be able to write any
>> interesting apps
>> with an @safe main.
>
> Without knowing any details of why your app wouldn't compile as @safe,
> there's nothing useful nor actionable in the complaint.
>
> There also is a conflation of two issues in the complaint - compiling
> programs that are unsafe despite being marked @safe, and the compiler
> complaining about unsafe code in code you'd like to be marked @safe.
> Which is it?

For me, it's the latter, but the issues with the former make it hard to trust either all that much.

I've fixed some of the issues in a couple bursts of activity over the last several years, and filed a bunch more bugs, but the specifics aren't the point I'm raising here, though your trimming of the thread dropped that part of the context.  You dismissed complaints of the incompleteness of safety as the whining of non-users.  I'm a user.  I was a much more frequent user until I got tired of the sheer number of only partially complete nature of so much of the language + core library.  Yes they're separate, no that's not relevant to the majority of users.  Yes, I can and have contributed to the fixes, but it's clearly (just based on commit history) not a priority to many people.

The D ecosystem is a large pile of incomplete features, with more added all the time.

On Tue, Jun 07, 2016 at 05:39:37AM +0000, ketmar via Digitalmars-d wrote:
> On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote:
> > Echoing the need for decimal support. I won't use it myself, but I know it's critical for finance.
> 
> funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects).
[...]

A Decimal type isn't hard to implement as a user-defined type. I don't understand the obsession with some people that something must be a built-in type to be acceptable... user-defined types were invented for a reason, and in D you have the facilities of making user-defined types behave almost like built-in types in a way no other language I know of can.

Same thing goes with a fixed point type. People keep complaining about it, but honestly if I were in the finance sector I'd implement the type myself in a couple o' days and put it up on code.dlang.org or something. It's not *that* hard.


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote:
> Echoing the need for decimal support. I won't use it myself, but I know it's critical for finance.

funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects).

i'd say: "you want it? DIY or GTFO."

On Tuesday, 7 June 2016 at 05:38:25 UTC, H. S. Teoh wrote:
>
> Same thing goes with a fixed point type. People keep complaining about it, but honestly if I were in the finance sector I'd implement the type myself in a couple o' days and put it up on code.dlang.org or something. It's not *that* hard.

i've seen some implementations already (and, of course, made my own too). it is not that hard, and it working nice. so yes, i'm all for that. and literals of various custom types can be implemented with CTFE magic, like `octal!`, for example.

On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
> The D ecosystem is a large pile of incomplete features, with more added all the
> time.

Even with only array bounds checking, D is safer than C++.

On Tuesday, 7 June 2016 at 05:38:25 UTC, H. S. Teoh wrote:
> On Tue, Jun 07, 2016 at 05:39:37AM +0000, ketmar via Digitalmars-d wrote:
>> On Monday, 6 June 2016 at 05:49:53 UTC, Ethan Watson wrote:
>> > Echoing the need for decimal support. I won't use it myself, but I know it's critical for finance.
>> 
>> funny thing: those "financial sector" most of the time doesn't give anything back. adding special decimal type complicating the compiler and all backends. i myself never needed that for my whole lifetime (and this is more than two decades of programming, in various free and commercial projects).
> [...]
>
> A Decimal type isn't hard to implement as a user-defined type. I don't understand the obsession with some people that something must be a built-in type to be acceptable... user-defined types were invented for a reason, and in D you have the facilities of making user-defined types behave almost like built-in types in a way no other language I know of can.
>
> Same thing goes with a fixed point type. People keep complaining about it, but honestly if I were in the finance sector I'd implement the type myself in a couple o' days and put it up on code.dlang.org or something. It's not *that* hard.
>
>
> T

In my opinion passionate D developer will build the missing parts themselves. I also developed my own decimal library. But the developers starting with D and which rather want to build content instead of the missing parts won't. Also there is a much higher trust if a library is provided within phobos than provided from a single person in terms of long time support.

Kind regards
Andre

On Tuesday, 7 June 2016 at 06:22:50 UTC, Walter Bright wrote:
> On 6/6/2016 10:38 PM, Brad Roberts via Digitalmars-d wrote:
>> The D ecosystem is a large pile of incomplete features, with more added all the
>> time.
>
> Even with only array bounds checking, D is safer than C++.

+inf. this feature alone made me much more productive, and took away alot of pain. (dreaming) if only RangeError could show invalid index too...