Comment by Razengan

> GP: For one thing, Swift is hardly ready for application domains like audio, video or games.

> For instance, I built a toy data-driven ECS implementation in Swift to see just what kind of performance could be squeezed out of Swift, and it was possible to achieve quite impressive performance

I also have a pure-Swift ECS game engine [0] where I haven't had to worry about performance yet; it's meant to be 2D-only though I haven't really yet put it to the test with truly complex 2D games like massive worlds with terrain deformation like Terraria (which was/is done in C# if I'm not mistaken) or Lemmings, and in fact it's probably very sloppy, but I was surprised to see it handling 3000+ sprites on screen at 60 FPS, on an iPhone X.

- They were all distinct objects; SpriteKit sprites with GameplayKit components.

- Each entity was executing a couple components every frame.

- The components were checking other components in their entity to find the touch location and rotate their sprite towards it.

- Everything was reference types with multiple levels of inheritance, including generics.

- It was all Swift code and Apple APIs.

Is that impressive? I'm a newb at all this, but given Swift's reputation for high overhead that's perpetuated by comments like GP's, I thought it was good enough for my current and planned purposes.

And performance can only improve as Swift becomes more efficient in future versions (as it previously has). If/when I ever run into a point where Swift is the problem, I could interop with ObjC/C/C++.

SwiftUI and Combine have also given me renewed hope for what can be achieved with pure Swift.

I actually spend more time fighting Apple's bugs than Swift performance issues. :)

[0] https://github.com/InvadingOctopus/octopuskit