5 ms·

Yes and here is a really great talk from Miguel de Icaza about some of the history of adding C# to game engines, and why he's excited about using Swift in Godot

by zengid 3y ago

Yes and here is a really great talk from Miguel de Icaza about some of the history of adding C# to game engines, and why he's excited about using Swift in Godot because he claims that Swift's reference counting avoids the issues of GC pauses. https://youtu.be/tzt36EGKEZo?si=WNxwcTPGFbJABKez https://youtu.be/tzt36EGKEZo?si=WNxwcTPGFbJABKez

pjmlp 3y ago
Based on his experience with Mono, less so with .NET proper. Also given the state of Swift outside Apple ecosystem, I guess he only plans to target developers on their platforms.
- TillE 3y ago
  De Icaza suggests that the GC hasn't improved sufficiently even in the modern .NET era, and maybe that's true in certain cases. But in practice, dozens of big-budget 3D games have been made with Unity, using a janky old Mono runtime that performs far worse than .NET 8. Swift is a really interesting language, and Apple does distribute official toolchain binaries for Linux and Windows. But yeah it's still a bit of an awkward choice if you're not using Xcode, hopefully that improves.
  - neonsunset 3y ago
    There is no such thing as a free lunch :) Modern GC implementations offer an important advantage - very cheap allocations and batched deallocations which allow to sustain high allocation traffic that goes through the heap. This comes at a cost of non-deterministic memory usage and object de-allocation. Further tradeoff is made between GC pause times, allocation throttling (Go) and even higher memory footprint (ZGC). My knowledge on the exact overhead of Swift's reference counting is very limited but there's a good chance it comes with significant upfront cost that you don't have to pay in languages with GC or with compile-time-defined allocation semantics (Rust and C++ RAII). There's a reason why Apple invested in atomics being as cheap[0] as they are on their ARM64 cores. Overall, every time I find Swift benchmark numbers on the internet, they turn out to be far[1][2] from near-Rust performance despite being a language built on top of LLVM. [0] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html (e.g. CAS, CASAL, DMB) [1] https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages [2] https://github.com/jinyus/related_post_gen#multicore-results https://github.com/jinyus/related_post_gen#multicore-results
  - pjmlp 3y ago
    C# is now following the same adoption patterns as C and Pascal dialects when games were in Assembly, C++ when games were mostly C. CAPCOM has their own engine based on a fork from .NET Core, used it on Devil May Cry for the PlayStation 5. Good luck getting similar adoption for Swift outside Apple platforms, specially game consoles. If not C# alongside C++, studios would rather use Rust not Swift, e.g. Embark and Activision. Metal has now C++ bindings, as Apple had to cede Objective-C and Swift bindings weren't being welcomed by major studios. I like Swift, however I don't see SwiftGodot going anywhere outside iDevices. That isn't bad if that is the goal though, plenty of companies are doing quite well being single platform.
    - zengid 3y ago
      I agree here, and I think Icaza is just motivated to make something for himself, because as he explained in the talk, he loves Apple products and APIs. Swift cross-platform would be a great thing.. I see that The Browser Company is using it for their browser project [0]. It's got a good mix of speed and ergonomics, and Apple seems hell bent on using swift for everything, even at the kernel level (I can't look up sources atm but Sean Parent has said this on ADSP podcast, and you can see the various talks from C++ conferences about swift as a "successor language"). You're right though, Swift is always going to be beholden to Apples whims, just like C# and Microsoft. I feel like Rust has the best shot at being "the cross-platform language to rule them all", but it has a long way to go in terms of being as ergonomic as Swift or C#. [0] https://speakinginswift.substack.com/p/interoperability-swifts-super-power https://speakinginswift.substack.com/p/interoperability-swif...
cyber_kinetist 3y ago
Note that GDScript (the primary scripting language for Godot) also uses reference counting for its memory management, so it doesn't have the GC pause issues. This isn't just a language-specific feature and is actually one of the core design decisions made in the C++ engine. Almost every object in Godot inherits the RefCounted base class - as a consequence even in C# scripting mode Godot-specific objects generally have reference counting semantics (and therefore also provides the WeakRef type to deal with reference cycles yourself.)
- zengid 3y ago
  > Note that GDScript (the primary scripting language for Godot) also uses reference counting for its memory management, so it doesn't have the GC pause issues. This is a great point, and something someone pointed out in the Q/A portion at the end.. I don't think Icaza cared though, he seemed very motivated to slay the dragons of his past and make good after working so hard to integrate C# into Godot. There's another talk about the GDScript from the same conference that I've been meaning to finish watching: https://www.youtube.com/watch?v=WNR4Tne5DRE https://www.youtube.com/watch?v=WNR4Tne5DRE

by zengid 3y ago

pjmlp 3y ago

Based on his experience with Mono, less so with .NET proper. Also given the state of Swift outside Apple ecosystem, I guess he only plans to target developers on their platforms.

TillE 3y ago
De Icaza suggests that the GC hasn't improved sufficiently even in the modern .NET era, and maybe that's true in certain cases. But in practice, dozens of big-budget 3D games have been made with Unity, using a janky old Mono runtime that performs far worse than .NET 8. Swift is a really interesting language, and Apple does distribute official toolchain binaries for Linux and Windows. But yeah it's still a bit of an awkward choice if you're not using Xcode, hopefully that improves.
- neonsunset 3y ago
  There is no such thing as a free lunch :) Modern GC implementations offer an important advantage - very cheap allocations and batched deallocations which allow to sustain high allocation traffic that goes through the heap. This comes at a cost of non-deterministic memory usage and object de-allocation. Further tradeoff is made between GC pause times, allocation throttling (Go) and even higher memory footprint (ZGC). My knowledge on the exact overhead of Swift's reference counting is very limited but there's a good chance it comes with significant upfront cost that you don't have to pay in languages with GC or with compile-time-defined allocation semantics (Rust and C++ RAII). There's a reason why Apple invested in atomics being as cheap[0] as they are on their ARM64 cores. Overall, every time I find Swift benchmark numbers on the internet, they turn out to be far[1][2] from near-Rust performance despite being a language built on top of LLVM. [0] https://dougallj.github.io/applecpu/firestorm-int.html https://dougallj.github.io/applecpu/firestorm-int.html (e.g. CAS, CASAL, DMB) [1] https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages [2] https://github.com/jinyus/related_post_gen#multicore-results https://github.com/jinyus/related_post_gen#multicore-results
- pjmlp 3y ago
  C# is now following the same adoption patterns as C and Pascal dialects when games were in Assembly, C++ when games were mostly C. CAPCOM has their own engine based on a fork from .NET Core, used it on Devil May Cry for the PlayStation 5. Good luck getting similar adoption for Swift outside Apple platforms, specially game consoles. If not C# alongside C++, studios would rather use Rust not Swift, e.g. Embark and Activision. Metal has now C++ bindings, as Apple had to cede Objective-C and Swift bindings weren't being welcomed by major studios. I like Swift, however I don't see SwiftGodot going anywhere outside iDevices. That isn't bad if that is the goal though, plenty of companies are doing quite well being single platform.
  - zengid 3y ago
    I agree here, and I think Icaza is just motivated to make something for himself, because as he explained in the talk, he loves Apple products and APIs. Swift cross-platform would be a great thing.. I see that The Browser Company is using it for their browser project [0]. It's got a good mix of speed and ergonomics, and Apple seems hell bent on using swift for everything, even at the kernel level (I can't look up sources atm but Sean Parent has said this on ADSP podcast, and you can see the various talks from C++ conferences about swift as a "successor language"). You're right though, Swift is always going to be beholden to Apples whims, just like C# and Microsoft. I feel like Rust has the best shot at being "the cross-platform language to rule them all", but it has a long way to go in terms of being as ergonomic as Swift or C#. [0] https://speakinginswift.substack.com/p/interoperability-swifts-super-power https://speakinginswift.substack.com/p/interoperability-swif...

cyber_kinetist 3y ago

Note that GDScript (the primary scripting language for Godot) also uses reference counting for its memory management, so it doesn't have the GC pause issues. This isn't just a language-specific feature and is actually one of the core design decisions made in the C++ engine. Almost every object in Godot inherits the RefCounted base class - as a consequence even in C# scripting mode Godot-specific objects generally have reference counting semantics (and therefore also provides the WeakRef type to deal with reference cycles yourself.)

zengid 3y ago
> Note that GDScript (the primary scripting language for Godot) also uses reference counting for its memory management, so it doesn't have the GC pause issues. This is a great point, and something someone pointed out in the Q/A portion at the end.. I don't think Icaza cared though, he seemed very motivated to slay the dragons of his past and make good after working so hard to integrate C# into Godot. There's another talk about the GDScript from the same conference that I've been meaning to finish watching: https://www.youtube.com/watch?v=WNR4Tne5DRE https://www.youtube.com/watch?v=WNR4Tne5DRE