November 27, 2020
On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:
> On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:
>> https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations
>
> Oops forgot to add my text
>
> As maybe people said, the industry doesn't mind the GC, as long as the job is done in an efficient way, GO gc seems to scale super well, since GO is opensource, is it possible to somewhat copy their GC, add their GC as a custom GC (since you can setup your own GC in D)

That web page was for servers... No, we cannot copy their GC. Also, Go code is slowed down because of it.

The easy path to fast GC with LLVM is single threaded.
November 27, 2020
On Friday, 27 November 2020 at 07:36:04 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:
>> On Thursday, 26 November 2020 at 23:09:12 UTC, ryuukk_ wrote:
>>> https://technology.riotgames.com/news/leveraging-golang-game-development-and-operations
>>
>> Oops forgot to add my text
>>
>> As maybe people said, the industry doesn't mind the GC, as long as the job is done in an efficient way, GO gc seems to scale super well, since GO is opensource, is it possible to somewhat copy their GC, add their GC as a custom GC (since you can setup your own GC in D)
>
> That web page was for servers... No, we cannot copy their GC. Also, Go code is slowed down because of it.
>
> The easy path to fast GC with LLVM is single threaded.

Better be usable at game servers or game related pipeline tooling, than not being used anywhere, but I guess the community is fine with Go, Java and C# owning that piece of the pie.
November 27, 2020
On Friday, 27 November 2020 at 08:11:40 UTC, Paulo Pinto wrote:
> Better be usable at game servers or game related pipeline tooling, than not being used anywhere, but I guess the community is fine with Go, Java and C# owning that piece of the pie.

Why would one of the current GCs be a problem on a server?

Memory? Well, in that case Rust will win.
November 27, 2020
On Friday, 27 November 2020 at 07:36:04 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 26 November 2020 at 23:10:41 UTC, ryuukk_ wrote:
>
> The easy path to fast GC with LLVM is single threaded.

But only if the thread has low memory footprint. The downside of a fast scan is that it may wipe out all caches, thus slowing down nongc threads.

To combat that you either need memory barriers to get incremental collection, which most likely require a language change, or you can only collect very slowly.

So well, ARC.



November 27, 2020
On Friday, 27 November 2020 at 09:00:02 UTC, Ola Fosheim Grostad wrote:
> On Friday, 27 November 2020 at 08:11:40 UTC, Paulo Pinto wrote:
>> Better be usable at game servers or game related pipeline tooling, than not being used anywhere, but I guess the community is fine with Go, Java and C# owning that piece of the pie.
>
> Why would one of the current GCs be a problem on a server?
>
> Memory? Well, in that case Rust will win.

It wouldn't, hence why I think it is better outcome focusing on proving a good experience on engines like Godot, similar to what C# already enjoys today.

Making this https://github.com/sheepandshepherd/godot-d-plugin appear here https://docs.godotengine.org/en/stable/tutorials/plugins/editor/making_plugins.html, would do so much more for adopting D in game development circles than yet another half baked attempt to reboot the GC.

Meanwhile, indie devs will start with something like Godot, search the web for how to continue, land on https://dotnet.microsoft.com/apps/games and carry on from there, regardless of what the community keeps trying to do to atract an imaginary set of game developers, because "booooo GC".
November 27, 2020
On Friday, 27 November 2020 at 09:16:57 UTC, Paulo Pinto wrote:
> https://docs.godotengine.org/en/stable/tutorials/plugins/editor/making_plugins.html, would do so much more for adopting D in game development circles than yet another half baked attempt to reboot the GC.

Maybe something for people interested in existing frameworks. I am more interested in WASM and ARC is the only sensible solution.

November 27, 2020
On Friday, 27 November 2020 at 05:20:11 UTC, rikki cattermole wrote:
> On 27/11/2020 12:11 PM, ryuukk_ wrote:
>> Why no EDIT feature on the forum? i shouldn't type after drinking this much for thanksgiving lol
>
> This is not a forum. It is a mailing list with a fancy web interface.

It's a newsgroup with a mailing list interface and a fancy web interface.
November 27, 2020
On Friday, 27 November 2020 at 09:16:57 UTC, Paulo Pinto wrote:
>
> Meanwhile, indie devs will start with something like Godot, search the web for how to continue, land on https://dotnet.microsoft.com/apps/games and carry on from there, regardless of what the community keeps trying to do to atract an imaginary set of game developers, because "booooo GC".

+1

It's all about having top-down libraries that nails one domain.
- having a library that allows to do X where X is not trivial
- **with a nice API**, this is the styling on the car
- being willing to manage/engage a community around that lib
- having a plan for monetization

Godot has incredibly nice API.
It can make 2D games.
It's quite innovative with the nested pre-fab, however it's not sure it's a big factor in its success.
It needs dedication!

Libraries are like products, they must sell some big goal, not "parse this format" which is a bottom-up approach. Products are top-down.
November 27, 2020
On Friday, 27 November 2020 at 14:56:03 UTC, Guillaume Piolat wrote:
> It's all about having top-down libraries that nails one domain.
> - having a library that allows to do X where X is not trivial
> - **with a nice API**, this is the styling on the car

Yes, but that is not a language feature.

If you want to create a framework like that you are better off stripping down flutter and implement the gameworld in Dart: instant support for ios, android and web.

November 27, 2020
On Friday, 27 November 2020 at 15:08:38 UTC, Ola Fosheim Grostad wrote:
> On Friday, 27 November 2020 at 14:56:03 UTC, Guillaume Piolat wrote:
>> It's all about having top-down libraries that nails one domain.
>> - having a library that allows to do X where X is not trivial
>> - **with a nice API**, this is the styling on the car
>
> Yes, but that is not a language feature.

I'm not discounting that D is a nice language (if people say they can't use anything else after knowing D, that says a lot really), I'm saying that the traits that make people switch to a new language are desirable properties of the _library they want to use_, more than the language.
It has been proven in research papers about programming language adoption.


> If you want to create a framework like that you are better off stripping down flutter and implement the gameworld in Dart: instant support for ios, android and web.

Soft disagree. This sounds to me like a high-debt solution.
If you make a game engine for example, cost of making N games is O(N), but cost of having a new platform is O(1). If added value flow to the game engine properly, you _will_ end up having support for all platforms needed.

You can totally start with only one platform (aka segmentation), actually Unity has started with a one plateform:
https://techcrunch.com/2019/10/17/how-unity-built-the-worlds-most-popular-game-engine


> Its story began on an OpenGL forum in May 2002, where Francis posted a call for collaborators on an open source shader-compiler (graphics tool) for the niche population of Mac-based game developers like himself. It was Ante, then a high school student in Berlin, who responded.

Unity had one platform and solved a smaller problem.