On Tuesday, 7 June 2016 at 13:15:38 UTC, Steven Schveighoffer wrote:
> My opinion, the first optional one to include is the forking GC, since it has been in production for years for one company. We may even find some bugs in it to help out Sociomantic, since they have discovered and helped fix so many problems with D :)

Dicebot even ported it to D2 about year ago. but afair it has some unsolvable corner cases, like deadlocking if one of the threads is malloc'ing while forking, or something like that. Dicebot probably knows better.

On 6/7/16 9:29 AM, ketmar wrote:
> On Tuesday, 7 June 2016 at 13:15:38 UTC, Steven Schveighoffer wrote:
>> My opinion, the first optional one to include is the forking GC, since
>> it has been in production for years for one company. We may even find
>> some bugs in it to help out Sociomantic, since they have discovered
>> and helped fix so many problems with D :)
>
> Dicebot even ported it to D2 about year ago. but afair it has some
> unsolvable corner cases, like deadlocking if one of the threads is
> malloc'ing while forking, or something like that. Dicebot probably knows
> better.

Right, but without a way to try it out, you will never get any help. I'm not sure of Dicebot's preferences, but I can imagine porting Sociomantic's GC to D2 may not be his preferred task. So doing something you don't want to do (possibly) with no help doesn't usually lead to a successful outcome.

I just read elsewhere that a GSoC student is working to achieve the goal of making the GC swappable and adding Reiner's precise scanning GC. I consider this to be essential work, I hope we can get this rolling soon!

-Steve

On Tue, Jun 07, 2016 at 12:49:55AM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/7/2016 12:07 AM, Brad Roberts via Digitalmars-d wrote:
[...]
> > This minimization and deflection of real user feedback is rather disappointing and somewhat insulting.  Instead, I'd prefer to see acceptance that it's an actual issue and not hand waved away as not really a problem of current, real, users.
> 
> I cannot do anything with handwaving statements, whether I accept them and hang my head in shame or not. Although I may have missed some, or some may not be tagged properly, I found only one bugzilla issue from you tagged 'safe':
> 
> https://issues.dlang.org/show_bug.cgi?id=13607
> 
> Here is the complete list of issues tagged with 'safe':
> 
> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced
> 
> Writing up specifically what problems you're having would be most appreciated.

I can't seem to find an issue I filed some years ago about @safe needing to be whitelist-based rather than blacklist-based. Did it get closed while I wasn't looking?

The problem is that D, being as complex as it is, has far too many corner cases and unanticipated feature combinations, that there is always going to be something that violates @safe in some way that we hadn't anticipated.  Currently, @safe is implemented as what's effectively a blacklist: code is assumed to be @safe by default, unless they use one of a set of features deemed unsafe. This means unanticipated unsafe corner cases will be assumed @safe by default.

A better approach would be to assume that *everything* is unsafe, and then whitelist those operations that are verifiably @safe. Yes, at first it will be almost impossible to write @safe code because the compiler will complain about everything, but as the whitelist is expanded more code becomes compilable in @safe, and we at least would have the confidence that unanticipated corner cases will be assumed unsafe. If they actually turn out to be @safe afterwards, we can always add them to the whitelist, and in the meantime we have the confidence that no code in the wild is actually unsafe while assumed to be @safe. Whereas right now, it's hard to be confident that code marked @safe doesn't contain some unexpected feature combination that is actually unsafe, but that we just haven't caught it yet.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev

On Monday, 6 June 2016 at 19:44:12 UTC, Satoshi wrote:

> When I told of D to my boss he had a couple of reasons why not to use D for development of our products.
>
> * Backward compatibility with existing code.

It's never a good idea to introduce a new language, not matter which, into a long standing project. If your new code builds/depends on old code then stick to the language the project is written in. Introducing a new language would be more for new (ideally independent) projects. So this is _not_ an argument against D, but about switching languages midway in general.

> * D is much more complex than C++

D is not easy, but I'd say it's at least more structured than C++ (less dead weight).

> * Not enough tutorials and solved problems in D on stack overflow (LOL)
> * We have problem to recruit a good C++ not a good D programmer. (1/100 is good)

Again, this is not about the language, but about finding exceptionally good people. Then again, maybe someone who's really into D might be very good, because s/he does it out of genuine interest in programming, not just as a job.

> * My boss does not have free time to learn new things...

Well, I think this is one of the _real_ reasons people don't adopt D. Too much work to learn a new language (any language not just D).

> * Using GC is strictly prohibited in realtime apps. And D does not have an compiler supported ARC
> * D without GC or ARC is not powerful as it can be.

Examples?

> * More and more people are dumber, we must write our programs for later re-usage by any junior what we must employ. C++ is in this way much more easier than D, cuz you know what every line of your program do. Employ C++ junior programmer and let him to learn D and then work on our projects is not a good (and cost-effective) idea.

This kind of thinking is very common and is one of the reasons IT is still stuck with outdated languages. It's this terrible must-work-out-of-the box thinking, meaning that the new employee has to be able to contribute code from day one, if not, s/he'll not be hired. It's a vicious circle you can't get out of. A has to know B, and we use B, because A knows B. In this way, no progress will ever be made.

Why not invest a little time in educating employees? If s/he understands C++, D is not that hard to pick up. A little investment pays off in the future.

> * Not everyone is interested in programming, sometimes people are doing it just for money.

Well, with these people things will never progress. But we shouldn't make our future dependent on the complacent and disinterested. They never innovate.

Sorry, but most reasons given by your boss are very general and could be applied to any new technology. It has nothing to do with D.

On Tuesday, 7 June 2016 at 09:03:15 UTC, Russel Winder wrote:
> Where there is some giving back is organizations that work with the financial institutions. Python has a number of organizations contributing to Python and library development who get their income by training or consulting to financial institutions.

Btw, I just found this on pony-lang:
https://www.infoq.com/presentations/pony

I guess one model is for the language-creator to do consulting/implementation for the industry and make the improvements on the compiler/libraries available.

But Pony is a rather unique language regarding compile time guarantees.

On Tuesday, 7 June 2016 at 13:39:19 UTC, Steven Schveighoffer wrote:
> I just read elsewhere that a GSoC student is working to achieve the goal of making the GC swappable and adding Reiner's precise scanning GC. I consider this to be essential work, I hope we can get this rolling soon!

https://github.com/dlang/druntime/pull/1581

On Tuesday, 7 June 2016 at 09:45:36 UTC, Russel Winder wrote:
> Jane Street are indeed well-known and well-renowned for their work with OCaml. It works for them but remains a small niche with little traction.

Perhaps, but my point is that there's a company that adopted a less-known language without starting out with any grand plan to do so, and they clearly have contributed very substantially to that language community in terms of money and I would guess code (as well as hiring key people from Ocaml community).

> Bloomberg actually do a significant amount of indirect give-back for C++ and a little for Java: they do a lot of sponsoring of C++ events and have staff on standards committees. We at ACCUConf like Bloomberg.
>
> I haven't been aware of Scala give-back from Morgan Stanley, I shall hunt it out. The organizations I know using Scala generally stay pretty quiet about it other than they are using it. Ditto for Python.

So perhaps you might agree that just the few examples that immediately came to mind demonstrate that it isn't the case finance doesn't and wouldn't give back.  I don't know the details of MS involvement with Scala (except that they use it), but a Scala guy I talked to was concerned that they were having too much influence of the development of the language - so I guess there must have been some money and code involved.


>> Finance is just one more industry, but it's quite a pragmatic one and still has a decent share of global IT spending.
>
> I have made quite a lot of my income over the last 7 years from finance industry, commercial banking and hedge funds, I am not complaining. :-)

Glad to hear.  But maybe in that context one should be thoughtful about suggesting entire industries are unpromising targets.  It's quite heterogeneous, and hard to speak in broadbush terms.

On Monday, 6 June 2016 at 14:10:57 UTC, Dave wrote:

>
> One thing I mentioned in another post is the documentation is lacking...particularly parts don't work and the examples are rather chaotic.
>
> As I dig into the language further (for some reason I haven't determined why yet) I also find that the standard library is has big giant holes. Particularly in the graphics department, which pretty much was a deal killer for my project I was gonna try using D with. But also it seems to be missing formal data structures that it should have. Deques, Queues, Stacks, etc. Also no formal official http support is also a bummer...

Would this be of interest for you:

http://dlang.org/phobos/std_container_dlist.html
http://dlang.org/phobos/std_container_slist.html
http://dlang.org/phobos/std_container_array.html

> I would dismiss this as "growing pains for a new language" then you find out D is almost 20 years old O.o

...but maintained by how many people on a voluntary basis? You have to take the restricted resources into account as well. It's not like 20 years + Apple or Google behind it. Given how slowly big languages like Java have progressed over the years, one can only admire the wealth of (sometimes innovative) features D has, implemented by a small number of core developers.

On Tuesday, 7 June 2016 at 13:47:39 UTC, H. S. Teoh wrote:
> .
>
> I can't seem to find an issue I filed some years ago about @safe needing to be whitelist-based rather than blacklist-based. Did it get closed while I wasn't looking?


This one?

http://forum.dlang.org/post/mailman.2912.1465288884.26339.digitalmars-d-bugs@puremagic.com

-Steve

On Tuesday, 7 June 2016 at 14:16:03 UTC, Chris wrote:
> It's not like 20 years + Apple or Google behind it. Given how slowly big languages like Java have progressed over the years, one can only admire the wealth of (sometimes innovative) features D has, implemented by a small number of core developers.

The problem with that reasoning is that the standard libraries of languages like C++, Java and Python are less likely to contain undocumented bugs. Which is more important than features.

The sole purpose of a standard library is to have something very stable to build your own libraries upon. A large number of features in a standard library is not really a selling point for production work.

Having a large number of independent narrow high quality maintained 3rd party libraries is a selling point. The role of a good standard library is to enable writing narrow independent libraries that can be combined.

This is an area where many languages go wrong. Basically, if there is no significant demand for a feature from library authors then it probably should not be added to a standard library.

Arcane bloat becomes baggage down the line and can even keep the language itself from evolving. (breaking your own standard library is much worse than breaking 3rd party frameworks)