On Thursday, 11 June 2015 at 03:04:50 UTC, Rikki Cattermole wrote:
> The biggest difference between the D community in general and other communities is actually quite simple.
>
> Experience.

Indeed! The world has never seen a more experienced collection of freshmen language designers. Theory does not apply.

Rust and Go are doomed.

> That's right. As mentioned we accept bugs, we accept issues.

Submit and accept, no regrets.

> Discuss them at length and fix them when a good solution is found.

A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy.

A non-breaking solution will eventually be found. Time is no issue in such an important matter. We just wait and a solution will emerge, through discussions based on pure experience.

> Not only that but we look for problems to fix.
> This is the mentality of a good software engineer. One who doesn't care about their own pride or ego but genuinely wants to make good code.

This community is the UNICEF of programming. We are all meek and humble individuals, divine servants of humanity.

People in these forums all express gratitude when they are on the loosing end of a technical debate. Nobody go silent or resort to rhetorical excesses. Ever. We are all grateful for being proven wrong, because that is how we become better programmers.

> In a lot of ways this makes us the best developers on the planet. It would explain a lot, including how other language communities snob us yet we look at them for ideas.

Indeed, we never snob anyone, and they all snob us. Especially the ignorant C++ community that never mentions us.

On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad wrote:
>
> A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy.

actually making a good GC for D is difficult because the only type of barrier you can use it hardware protection faults. The performance dropoff isn't _that_ bad from what I've read in various papers.

I should have an article up in a few weeks detailing my summer research project on this.

bye.

On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:
> On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad wrote:
>>
>> A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy.
>
> actually making a good GC for D is difficult because the only type of barrier you can use it hardware protection faults. The performance dropoff isn't _that_ bad from what I've read in various papers.
>
> I should have an article up in a few weeks detailing my summer research project on this.
>
> bye.

It IS that bad, and any paper that tell you otherwise is lying to you.

On Thursday, 11 June 2015 at 07:13:10 UTC, deadalnix wrote:
> On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:
>> On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad wrote:
>>>
>>> A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy.
>>
>> actually making a good GC for D is difficult because the only type of barrier you can use it hardware protection faults. The performance dropoff isn't _that_ bad from what I've read in various papers.
>>
>> I should have an article up in a few weeks detailing my summer research project on this.
>>
>> bye.
>
> It IS that bad, and any paper that tell you otherwise is lying to you.

after extensive testing I found a hardware protection fault + mprotect to take 2000nsecs on every hardware I tested, the only time you need them active is during a concurrent mark and sweep. I'll find out I guess.

Boehm's GC uses this and regularly kept up(~5-10%) with essentially all of the top of the line GCs in all the papers I read.

On Thursday, 11 June 2015 at 07:15:31 UTC, rsw0x wrote:
>
> Boehm's GC uses this and regularly kept up(~5-10%) with essentially all of the top of the line GCs in all the papers I read.

Ah, so you only read papers about very bad GCs, that explains it. ;)

On Thursday, 11 June 2015 at 07:45:49 UTC, thedeemon wrote:
> On Thursday, 11 June 2015 at 07:15:31 UTC, rsw0x wrote:
>>
>> Boehm's GC uses this and regularly kept up(~5-10%) with essentially all of the top of the line GCs in all the papers I read.
>
> Ah, so you only read papers about very bad GCs, that explains it. ;)

I don't consider immix, schism, or C4 to be a bad GCs.
but maybe we have different definitions.

On Wednesday, 10 June 2015 at 18:13:53 UTC, Dave wrote:
> D did get thread local storage correct, but I think people are
> starting to get on board with having restrictions by default
> because it prevents bugs (and the annotations are grepable). Kind
> of like what Rust is doing. If this is the case, D might find
> itself being discarded in favor of languages that offer better
> guarantees.

Chances are they prevent one bugs at the cost of causing other bugs and raising cost of software development, which in the end may be not a better guarantee. And you can't prevent bugs by learning languages instead of, well, bugs.

On Thursday, 11 June 2015 at 07:08:02 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 June 2015 at 03:04:50 UTC, Rikki Cattermole wrote:
>> The biggest difference between the D community in general and other communities is actually quite simple.
>>
>> Experience.
>
> Indeed! The world has never seen a more experienced collection of freshmen language designers. Theory does not apply.
>
> Rust and Go are doomed.

Now, now. It is true that bad and frustrating experience with other languages drove me (and probably others) to D. D is open to suggestions, while other languages still live by the "one size fits all" mentality. std.allocator is a good example of trying to offer a variety of different memory models. What's wrong with that?

People here often request features you can only ask for after years of programming experience. This shows that there is a lot of experience in the D community. Without experience D wouldn't be where it is, having only limited resources.

>> That's right. As mentioned we accept bugs, we accept issues.
>
> Submit and accept, no regrets.
>
>> Discuss them at length and fix them when a good solution is found.
>
> A ground breaking GC will emerge from the synthesis of the unsurpassable number of endless GC debates. That is the sanctimony of meritocracy.
>
> A non-breaking solution will eventually be found. Time is no issue in such an important matter. We just wait and a solution will emerge, through discussions based on pure experience.
>
>> Not only that but we look for problems to fix.
>> This is the mentality of a good software engineer. One who doesn't care about their own pride or ego but genuinely wants to make good code.
>
> This community is the UNICEF of programming. We are all meek and humble individuals, divine servants of humanity.

Just trying to create the best tool possible for our own daily tasks.

> People in these forums all express gratitude when they are on the loosing end of a technical debate. Nobody go silent or resort to rhetorical excesses. Ever. We are all grateful for being proven wrong, because that is how we become better programmers.

But we keep coming back. So it cannot be that bad ;)

>> In a lot of ways this makes us the best developers on the planet. It would explain a lot, including how other language communities snob us yet we look at them for ideas.
>
> Indeed, we never snob anyone, and they all snob us. Especially the ignorant C++ community that never mentions us.

Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of other languages saying "Da', can I have this, pleeeeeze?". All most of us do is to point out the strengths of D when ever the occasion arises, trying to convince people to at least give it a try. Of course it can be annoying when D is snobbed at while its features are being ripped.

Talking about UNICEF, feel free to be a humble servant of humani-D. The more the merrier!

On Thursday, 11 June 2015 at 07:11:33 UTC, rsw0x wrote:
> actually making a good GC for D is difficult because the only type of barrier you can use it hardware protection faults. The performance dropoff isn't _that_ bad from what I've read in various papers.
>
> I should have an article up in a few weeks detailing my summer research project on this.

That sounds like an interesting project!

I think it is possible to modify the language slightly and make (to me) acceptable restrictions on where GC is allowed to get better performance. Still, I am sure you will be able to find some new opportunities in your research project.

I am looking forward to see what you come up with.

On Thursday, 11 June 2015 at 09:14:00 UTC, Chris wrote:
> Because this hurts some people. The D crowd doesn't snob other languages, in fact, people here often point at features of other languages saying "Da', can I have this, pleeeeeze?".
http://forum.dlang.org/thread/mki78k$6k5$1@digitalmars.com?page=8#post-cnprllcbxwinzclvwtib:40forum.dlang.org