On Thursday, 7 December 2023 at 19:01:26 UTC, GrimMaple wrote:

A similar problem happens when @safe code calls @system callbacks. I recommend to make the callback setter to be declared @system and then cast it to @safe, so if something goes wrong, it's not your mistake.

On Monday, 11 December 2023 at 09:08:25 UTC, Kagamin wrote:

You can have @trusted callbacks in this case. It's just a matter of adding this attribute to each function after making an effort to attest that the function looks bug free despite using dangerous language features. Whereas the actual GC code can't just magically become @nogc if it actually relies on the garbage collector.

I'm not sure if I understand your suggestion correctly. If something goes wrong because you did something fishy, then it's probably your mistake after all.

On Sunday, 10 December 2023 at 10:34:37 UTC, aberba wrote:

I dont really agree with dlang already being used, we have a lot of dead libraries in DUB, and we hardly see new libraries comes into play. Also I dont think we should stick what d was 10 years ago, if we want to be success then we shoudln't be scared from changing.

On Friday, 8 December 2023 at 13:29:54 UTC, IGotD- wrote:

No, this is misinformation

Contact any game studio and tell me how they feel about the GC in Unreal/Unity

Tell me why do they have to work around it, specially on mobile and consoles

This is why game devs don't take D seriously, there is too much non-serious people pushing bad takes like this

On Monday, 11 December 2023 at 07:18:44 UTC, Dukc wrote:

Actually, having written D full time for over 2 years now (I chose D for my indie game stuff), I don't really see D excelling in pretty much anything. The only stuff where I'd barely consider using D now is its betterC stuff where it at least does as advertised, and even then getting C dependencies is problematic enough that I'd rather just use C in the first place. High level stuff though... Yeah, D goes straight into the bin. C# gets me where I need to be faster, even though the actual code writing is slightly slower. D has the potential to match it, but it all boils down to the lack of sane 3rd party libraries. Dub is a graveyard at this point. And when you have to reinvent the wheel all the time, it wears you down very quickly.

I would've definitely rephrased that to Consider the two probably **only** companies using D. I'm sorry, but this point is laughable, considering how many companies ditched D in comparison. Yeah, those two (and some more) are using D. But how many have moved on? Take a look at "D Success Stories" page, you will find that most of the corps listed there stopped using D a while back.

On Monday, 11 December 2023 at 17:54:52 UTC, ryuukk_ wrote:

They might have work around it like pausing the GC at times. However GC isn't going away and the benefits of it is not releasing a game that leaks.

GC the isn't going anywhere and if you look at new emerging languages, a majority of them has GC.

Disabling the MMU on CPU will make it faster but nobody does that for obvious reasons. Features has a cost.

Future games will have GC whenever you like it or not. Games are becoming more and more complex the benefit of having GC is obvious.

On Monday, 11 December 2023 at 18:28:10 UTC, GrimMaple wrote:

I guess everyone has their own story, but it's hard to understand what's difficult about using D to access C dependencies in 2023. That's been my use case for a decade and I have no desire to move to anything else. C compiler extensions and the preprocessor get in the way from time to time, but you just have to deal with that crap when you're working with C.

On Monday, 11 December 2023 at 18:28:10 UTC, GrimMaple wrote:

I still think that D's problem is how much work a single person needs to do.
Right now, I'll list projects that I'm maintaining that was supposed to be unrelated to my project:

• GLES Binding
• Metal Binding
• DirectX binding
• A custom runtime for being able to use real D on WASM
• OpenSL ES binding
• AVAudioEngine binding
• A custom build tool because dub is far from being enough to my purpose
• Windowing libraries because when I started it, I didn't knew about adam's simpledisplay
• Even JSON I had to reimplement, since the implementations I tested bring features which I don't have in my custom runtime, D code just seem to depend on everything, always.

Beyond that, I have forfeit:

• Phobos usage, since it is not portable enough for me, it breaks on releases, and it makes your compilation time go down a lot
• Code completion (I don't remember when it worked again on Windows)
• Go-to definition (yes, it is simply faster to just try to memorize in which file something was defined)
• Using C dependencies: this is more of a C problem, but I really find it hard to manage multiple dependencies from C with D, and this should be easier since this is what the language sells

Most of the problems we have is the lack of existing work. D's std coverage is very good, but has this big problem which is a lot more of a concern when you're not using it as a script.

I'm not that unhappy with D, but it is quite exhausting to beyond having to develop your project, develop the tools for helping you develop the project.

On Monday, 11 December 2023 at 20:29:36 UTC, Hipreme wrote:

Agreed - with the likes of Go, C#, Python, etc you have a wealth of libraries for things like Databases+ORMs, high performing (excluding Python) and well documented frameworks for things like web APIs or even server side rendering, and also easy just-works SDKs to access modern application development platforms (AWS; GCP, Azure if you're unfortunate enough), and so on.

When you don't have an easy to access, plug-and-play solution to access these external resources, for developers to tinker around with and prototype ideas with, then effectively a ton of more casual developers will never really touch D.

With D you just have to do it all from scratch yourself: Something I'm very very very slowly making progress towards, but ultimately I understand it's almost pointless in the long run.

However for things that do require you to make a lot of functionality from scratch, D definitely is pretty awesome to work with... if you have the time :(

On Monday, 11 December 2023 at 18:39:22 UTC, IGotD- wrote:

It is a misconception that having no Garbage Collector is bad or dangerous or silly. It is also misleading that (games programming specifically) will "benefit using a Garbage Collector as games get more complex."

Game programmers NEED CONTROL OF MEMORY. The only time I can see this ever changing is if hardware evolves at a faster rate than software. The reality is the opposite. game programmers have to squeeze every inch out of the hardware. Of course, I am referring to the AAA titles.

If you are making a 2D platformer, you could probably write it in Unity (and do a fairly poor job) and it will still run at 60fps on your PC. Of course, we are not talking about those games.

Performance is key and they are writing their own memory system. They also write it to suit the type of game they are making. They won't just use the default GC that comes bundled with a programming language.

Also, if there ever is going to be a C++ replacement in the gaming industry, I think Odin or Jai are going to win. They are not "GC languages"

On Monday, 11 December 2023 at 17:54:52 UTC, ryuukk_ wrote:

https://twitter.com/cmuratori/status/1167230252797480960