On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

Is this actually true? My understanding is that @nogc code fragments can be called from the GC code just fine. Though some problems may arise with callback functions or delegates/closures here and there. An example of @nogc induced friction:

import std;
void main() {
  auto a = new BigInt[](100);
  a[] = BigInt(1);  // works fine
  a[] += BigInt(1); // Error: `@nogc` function `core.internal.array.operations.arrayOp!
                    // (BigInt[], BigInt, "+=").arrayOp` cannot call non-@nogc function
                    // `std.bigint.BigInt.opOpAssign!("+", BigInt).opOpAssign`
}

Or do you mean that manual dynamic memory allocation/deallocation in the @nogc library can make things much more complicated? But if a @nogc library never exposes manually allocated memory slices to its API users, then everything is fine. In fact, various C libraries (such as glibc, zlib, sqlite) are all effectively @nogc and they can be used from D code.

On Thursday, 7 December 2023 at 10:08:14 UTC, Siarhei Siamashka wrote:

This seems to be an issue with the arrayOp template being annotated with function attributes. Filed as: https://issues.dlang.org/show_bug.cgi?id=24272

On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

Reminded me of my early days with VB6 and Turbo C (and Turbo Pascal)

I hated Java when I first tried it. Forced into this "everything is an object" mindset, and the books I was reading were 900 pages... half of which were understanding OOP in general, not specifically aimed at Java.

Then you have the C programming language book, which is barely 300 pages.

The late 90's was making me question the direction we were going and whether this was the career for me. OOP went through some transitions over the years but I will always remember watching Mike Acton data-oriented design to make me realise that I am not alone with my views.

Each to their own... and sorry for diverting the OP question.

#BackToTheQuestion.

On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

The Mike Acton that ended up working for Unity, as part of the DOTS team, helped design Burst compiler for C# and nowadays is still busy with C#, after leaving Unity.

On Thursday, 7 December 2023 at 11:50:44 UTC, Paulo Pinto wrote:

Yes (I didn't know he had left unity, tho)

On Thursday, 7 December 2023 at 14:08:03 UTC, Martyn wrote:

My remark was to made the point that regardless of his opinion on data-oriented design, he nowadays uses a programming language that is pretty much as OOP as Java is, even including the latest influences from FP that permeate both languages, as features are part of the OOP type system of both languages, e.g. lambdas are represented by specific classes/interfaces.

On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto wrote:

That's exactly why Unity went to shit and he left as a result, they picked the wrong language, so they wasted many years working on working around the language

That's what happen when you work with GC/OOP people, nothing good comes out of it, you get replaced by what ever is new and trendy

And then the people will exclude the people who care (Mike Acton) to empower the developprs who need assistance (GC/OOP) because these people can promote idiocracy, as opposed to meritocracy backed by tangible resulsts (how fast code run, and how efficient it is)

On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

And as always, the people who call themselfes "efficient" don't care for memory safety.
Everybody should use GC - not for assistence because of idiocracy, but as a fallback, because even the very best and most efficient developers can make mistakes. This is why all modern computer systems are full of loopholes. We should finally trash manual memory magagement - or at least put huge red warning lables on such products that they may be a little faster but can be very dangerous.

On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto wrote:

I know it was. I originally chose to ignore it, but hey... you got me.

I cannot speak for Mike Acton. I cannot comment why he joined Unity, either. On top of this - I am not a "Unity developer"

My guess is, after years at Isomniac Games, he saw a new opportunity and a challenge.. and accepted it. I dont think he accepted it primarily because he would be using C# or that its about OOP... it is far deeper than that! He is an Games Engine Developer/Lead.

Besides, are you suggesting that Mike has done nothing with C# beforehand? I am sure C# was used at Isomniac Games. C# might have been used for certain in-house editing tools.. perhaps even HTML/javascript in places.

This does not mean his views are no longer valid, especially his 2014 talk.

But I get it. The point of your reply is to put me in my place. That "Gotchya!" moment where everybody laughs.

You win... I mean.. whatever.

I prefer to leave that crap at the door. If Mike has changed views on certain things then I'm interested in hearing about them. Even John Carmack has spoken about using Python in recent years. It all depends what they are doing with them, I suppose.

If Mike is still 'doing stuff in C#' like the burst compiler then good for him. Sounds like he put a lot of effort into that project and does not want to walk away from it. Again.. point?

On Thursday, 7 December 2023 at 15:51:43 UTC, Dom DiSc wrote:

"Everybody should use GC"

Yes -- to a degree, you are correct in this statement. However, there is a difference to just using the default bundled in a programming language, or building your own -- when you have complete control of how the memory is laid out. It puts you in control.

You can even argue that DOOM, a game from the early-to-mid-90s, has some kind of GC.

I think it is a stretch to assume that (AAA engine programmers specifically) "dont care for memory safety" as you put it. I think they care very much and do heavy testing. The average web developer, on the other hand, don't even think about it at all.

I have nothing further to say on this, as we are moving away from the original OP query.