Why is D's GC slower than GO's? (page 20)

On 01.11.22 21:47, Don Allen wrote: > don't contribute code because they don't I have contributed code to DMD, I have contributed ideas and designs, (co-)wrote multiple accepted DIPs and even more drafts, and reported a lot of issues. I have contributed to other community projects as well, even when lacking the spare time. I have burned out as a result, more than once. I have also gone through a painful experience where I was explicitly asked by D leadership to work on a specific project instead of what I had considered important and then this line of work was just dropped later. > "have the spare time" Not everyone is in Walter's position. I really don't understand why you are singling me out here and being disrespectful towards me. I made that remark in a post where I was explicitly appreciative of the huge amount of work Walter is putting into D, but I still somewhat envy his ability to work so much on what he wants to work on. Other people have to report to their higher-ups and peers. Higher-ups and peers who will criticize them for even using D, let alone contributing to the compiler. I hope you understand that nowadays there are many people in jobs where open source contributions are a no go by default, _even_ in their spare time. It's generally much harder now to build something on your own that will be successful and last due to the proliferation of large tech monopolies, overbearing intellectual property laws and a general loss of freedom. Anyway, note that Walter has Ola in his kill file and so do I.

On Tuesday, 1 November 2022 at 22:43:57 UTC, Timon Gehr wrote: > On 01.11.22 21:47, Don Allen wrote: >> don't contribute code because they don't > >> "have the spare time" > > Not everyone is in Walter's position. I really don't understand why you are singling me out here and being disrespectful towards me. I was not and am not. It's a common phrase that I've seen in that past in these situations and that's what I was talking about. You'll note that something similar was said by someone else in this thread. Also, I was not aware that you had said anything like that. I haven't read every message in this thread. I'm also aware of the fact that you've contributed to the project, so it wouldn't make much sense for me to point the finger at you, would it? In any case, I'm sorry you were offended, but it was not intentional.

On 10/31/2022 9:46 AM, Adam D Ruppe wrote: > On Sunday, 30 October 2022 at 02:15:06 UTC, Walter Bright wrote: >> Besides, if it was so easy to do, why has nobody produced a C compiler that uses a GC instead of malloc/free? > > Well, it has been done with Bohem. D's GC is very similar to the Boehm one, but more accurate since the D compiler provides layout info to the GC. > But anyway I wrote up my sketch design in my blog: > http://dpldocs.info/this-week-in-d/Blog.Posted_2022_10_31.html > It is more like bounds checking than a new type. Sure, I do propose a new type, but just to locally bypass the thing, not as something mandatory. With a compiler switch, you can turn it on or off to experiment with different strategies. Thanks for doing that. Now, if someone wants to implement it ...

On 11/1/2022 3:05 AM, rikki cattermole wrote: > There is one concurrent GC implementation using the existing implementation that is left to be done, snap shotting on Windows. This is mostly just adding a tiny bit of code in what should have been very obvious points (sadly it isn't). Please pick up the flag and lead to victory!

On 11/1/2022 2:31 PM, ryuukk_ wrote: > Hijacking this thread since there seems to be lot of energy available here > > It would be cool if someone could take care of that issue: https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs@forum.dlang.org > > It's pretty concerning that this more than 1 year old bug still exist, quite dangerous bug If bugs aren't reported to https://issues.dlang.org they're pretty much guaranteed to be overlooked and forgotten. The forums make for a terrible bug database.

On Wednesday, 2 November 2022 at 01:04:03 UTC, Walter Bright wrote:

On 11/1/2022 2:31 PM, ryuukk_ wrote:

Hijacking this thread since there seems to be lot of energy available here

It would be cool if someone could take care of that issue: https://forum.dlang.org/thread/lxnogwxpuiwlxvruqlrs@forum.dlang.org

It's pretty concerning that this more than 1 year old bug still exist, quite dangerous bug

If bugs aren't reported to https://issues.dlang.org they're pretty much guaranteed to be overlooked and forgotten. The forums make for a terrible bug database.

It's already been reported

If you clicked that link, you'd have seen two bug reports:

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

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

November 02, 2022

Re: Is D really that bad?

Posted by cc
in reply to Guillaume Piolat

Permalink

Posted in reply to Guillaume Piolat

Permalink

On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat wrote:

the better it is, the more any perceived flaw is painted as huge and "show-stopper".

This is a truth I have encountered numerous times in game design. The more rich and rewarding your feature set and environment are, the more it generates a sense of "well, if only it was BETTER, THEN it would be just what I wanted!" The more restricted something is, the more content one remains with what has been accomplished within the bounds of the design.

And to respond to the OP, D is definitely good enough that I don't want to switch to anything else for this purpose when I don't have to! And by good enough, I mean great. I definitely feel D is the "should have been, but wasn't" language that C# ended up becoming for claiming the gaming industry (or at least squeezing alongside C++, which will sadly never leave us). It's just a joy to program in, the metaprogramming capabilities are fantastic. I don't know how to really quantify whether D does them "better" than other languages, but it always feels cleaner to me. I am not a language design expert, I am just a humble tiller of the soil that is allotted to me. But IMO D lets you write things that end up looking beautiful. I put together a quick RPC module to call functions on client objects from their server representations in a multiplayer game engine. All parameters matched for implicit conversions, marshaled, bundled and prepared for network sending. Hard compiler errors on any mismatches. Any method I want replicable, All I need to do is just drop a UDA onto it. No complicated lookup tables or list of mangles or serialization definition documents. No need to add any code or create stubs anywhere else in the project. It all "just works". The entire RPC module? 194 lines of code. Brings a tear to my eye. The thought of building the equivalent in C# gives me a headache. C++? Migraine. And I do not care for Rust.

On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:

in fact

d rox

This. Although I do agree that allocators should be tuned up and taken out of experimental. I would personally love to see alternative memory management strategies made to feel more "at home" as base language features, instead of tricks with structs and templates. Just my pipedream.

On Tuesday, 1 November 2022 at 00:16:32 UTC, Walter Bright wrote: > .. > .... > We've been known to incorporate projects people have done all on their own initiative. I've been known to ask the creators of such projects to donate them to D. > Well.. just as long that project doesn't involve providing 'an option' to the programmer, so the programmer can specify that a member of a class is private to that class. Anything else... fine.. he'll consider it...but 'private to the class' .. never!

Forums