Miguel de Icaza: Swift Godot: Fixing the Multi-million dollar mistake
Вставка
- Опубліковано 22 сер 2024
- media.ccc.de/v...
In a previous life, Miguel worked tirelessly to get Unity and other game engines to adopt .NET as a runtime to execute their game code, as it blended beauty and speed. And he dreamed that one day the pauses introduced by the garbage collector could one day be solved, but after decades this dream seems further away with each passing day. Meanwhile, a language of equal beauty and ergonomics emerged without any of these downsides. This talk will discuss both the rationale of the Swift bindings for Godot, as well as a bold proposal to integrate Swift into Godot itself.
Miguel de Icaza
pretalx.c3voc....
#godotcon2023 #Talks
Apple should support this for their VR Platform instead of Unity. I hope they will.
Totally
The unity support was really just a vindictive move against unreal.
@@reverse4646 Nope. If Apple goes with Unity, it will bring the entire .NET development platform over to Apple's ecosystem, freeing it from the chains of Swift and Objective-C.
I stumbled across this talk totally not intending to do anything programming related today... and while I haven't written Swift in years, I've always loved it. It's a wonderful language, and an absolute pleasure to use. I stopped because I moved to Linux and get paid to write Elixir, but this talk has me wanting to go write it again just to try SwiftGodot. Really excited from this talk about something I didn't even know existed an hour ago.
What a great talk! Learned a lot, never ever thought about swift before but he makes me want to try it!
Swift will really be ready for games when Embedded Swift is out to reduce or eliminate dependencies (like golang) on a particular Linux distribution, target game consoles, and maybe even cross-compile. The runtime metadata and reflection capabilities can be turned off for light binaries. This has me really excited for Swift outside of the Apple ecosystem. The vision document is on Swift Evolution and implementation is already in progress and running on some microcontrollers.
Apple has been very generous with the open sourcing and community. That includes inviting people on Windows/Android/Linux to core teams. They are quite genuine in their desire to have Swift replace C++ and the only language with full C++ interoperability. No C bindings needed.
Swift is already on the way to embedded platforms. Community managed to decrease executable size from 5mb down to 750kb with removal of unnecessary overhead metadata and features (according to their document in swift-evolution/visions/embedded-swift)
@@eldarliis8788 Yeah. This should also allow for easier cross-compiling and building for consoles.
Great talk, got me a little interested in swift
Haha. Me too. Used to use it when it came out but lost interest. Seems really cool to use it with Godot.
Me gustó mucho esta plática ya que de alguna manera Miguel de Icaza condensa y explica muy bien todas las características que se han desarrollado en Swift los últimos 10 años. Como desarrollador iOS se aprecia mucho.
I've never tried Swift but it seems like a nice trade-off vs. Rust, so you don't have to deal with the borrow checker all the time, but only in cases where you care.
Under the hood, Swift’s memory management model is identical to Rust’s, except instead of borrow checker errors, Swift synthesized implicit copies (or reference counting, in a Copy on Write context)
I love C# but this talk convinced me to give Swift a go for real-time apps like games. Now we just need the proper integration and tooling support (I'm a windows user..).
Excellent talk
Very interesting talk. 8:54 is on spot. By the time, you realize, you have a big problem, it is too late.
One question about swift: Does Apple/Swift treat none-apple swift user well? Do I (as a Linux user) get the latest versions in time and is the swift tooling well supported on other platforms than macOS? I don't want to use Swift when I get treated as a second class citizen.
One question about SwiftGodot: Where can I track the progress about the project? What target platforms are supported, what features are on the roadmap and so on?
You get the same Swift version on Linux (and now Windows) than on macOS. Windows support was marked as experimental for years, but it's available in stable form since recently.
I've only ever written Swift using Xcode, but you can probably get a good experience by using other IDEs as long as you're not looking to develop macOS/iOS apps with SwiftUI.
Of course they do, much like Microsoft treats Linux users... 😂
@@higaskinot sure if tongue in cheek or you've simply just not used "M$ Windoze" since that nonclementure was popular ...
@@higaski... or Windows users like me, who tolerate C# but have unconditional love for F# :v
I’ve had no issues running Swift on Linux FWIW! As long as you’re not expecting to have access to macOS/iOS UI stuff (e.g. SwiftUI) then you should be in good shape, especially as Foundation (a collection of useful-but-previously-proprietary fundamental components) is now part of the open-source Swift core libs!
Effectively, this makes many niceties that used to be exclusive to Apple platforms available anywhere Swift runs, with the goal to make code even more portable to Linux and Windows.
I hope Swift will eventually become an officially supported language by Godot just like C#. Coding games in Swift would be great!
If anything, C# support will become more like the Swift extension because GDExtensions are actually more flexible and allow way more control then the current C# hardcoded bindings can give you. As an example, in C#, there is pretty much no way to deal with things made in GDExtensions, because C# has no concept of GDExtensions as it was made before they existed and couldn't adopt anything about them. What this means is that if you make a GDExtension that adds say a terrain system, there is no quick and easy way to access it, most folks end up writing a binding in GDScript that translates the needed calls and variables from extension that can then be called from C#.
Probably only possible if someone pays them a ton of money. The C# implementation was sponsored by Microsoft.
Will great to have apple developers using Godot.
@@Spartan322 you can easily generate the C# bindings for the extensions yourself lol
when they added NativeAOT support in 4.0 the marshalling costs also went away, so you already have performance close to C++ with C#
the documentation of everything is just bad or completely inexistant, it needs a lot of reading through the source code to figure out on your own
I know Swift is fast (ex-iOS dev here), question: how does it compare to gdscript when used in Godot? My _only_ temptation to use C# was for performance, so if Swift has similar benefit then yeah, good riddance to C#. Thank you
Never did swift, but if it becomes a first class citizen i would prefer it to GDScript.
This is very interesting! The tutorial in the repo assumes one is using a Mac PC with XCode, but how would one get started on other platforms?
Swift can be used on Linux and Windows since 2019 👍 No need for a Mac to write Swift code
Nice talk, really fascinating. Love the way this guy talks
Miguel never stopped since the 90s. He started so many awesome projects like GNOME. I can't believe he did this for Godot and Swift. I really hope Godot just puts it in the next build.
so my dream of building watchOS games with Godot is alive?
@Volt-EyeCuz watches are discrete, and playing tetris is fun
Apple Watches have really limited RAM and processing power compared to even older iPhone models, so I doubt you can get a Godot 4 project running smoothly on one.
Porting full-blown PC games to watchOS has been done in the past, but only with old games like Quake 1/2 so far: github.com/ByteOverlord/Watch_Quake2
@Volt-Eye tbh I really like the restrictions the device imparts. there's challenges to overcome with such small screen size, limited input options, limited device capabilities - all of which creates an interesting design space.
@@Calinou SceneKit games run on watchOS. It really depends on the project.
I really like Swift. I use it in by job. This project brings me a hope to use Swift for something that is not iOS/MacOS development.
Though, I think Swift needs a big improvement on the cross-platform support. Yes, it's there but it's bare minimum at the moment imo.
There is simply no IDE other than Xcode now. VSCode can be used for Swift development but its features is not even half of what Xcode can do (And it's quite slow maybe my PC sucks ).
So the day when Swift gets a better cross-platform support, I will be super happy.
I'm looking to get a job as a Swift dev some day - atm i'm trying to determine what project should i make for a portfolio. Any suggestions? Thanks in advance!
great talk
i assumed "the mistake" was GDScript...
but i believe Icaza would be much more useful if he had put this effort into fixing the C# "second-class-citizenship" situation with Godot 4. With him is always the same modus operandi, with gnome, mono, xamarin, always moving to the next shining thing, and leaving the work half-done.
@@scififan698 long story short, it's cross platform, you can develop it on and build binaries for linux, windows, and android, but it still in an early stage and still evolving, it still heavily relies in the stdlib and some core libraries that need to be installed on the system, instead of being able to have a full self contained binary
The mistake was allowing null pointers in both C# and C++ and Swift fixes it and turns it into a non existent state.
100% agreed. He keeps jumping to the next shiny thing and never finished what he promised. For example, seamlessly FFI for C# to Java and OBJc, at the time.
very interesting talk!
which tool they used for write the documentation?
DocC
This was a really interesting talk, and really catches my attention to start experimenting with swift.
I have a question, I migrated from Unity a year ago and I’m super happy utilizing GDscript, it was such a soft transition from C#, but, I still love C#, I haven’t try it yet in Godot, because of many limitations in the engine, I know most of this limitations are being work in Godot 4.2.
My question is related with is swift production ready and if it’s possible to export to android, HTmL5, etc.
As someone who started trying around Swift for some time. I'd say it's about 70% there in actual usefulness, Swift binaries still rely quite heavily in the platform environment and you have to give up quite a bit for it to be self contained, so for example it can compile to Android, but you'd need to also ship the Swift stdlib for anything meaningful. Not fully there for 'industry grade' cross platform development, but is probably going to get there in a year or two if it keeps the same steam it has now
if i was there, i would’ve asked for his opinion on nim’s orc, basically reference counting with a small gc for cycles. nim doesn’t have stuff to catch null problems, at least not as well as i’d like. i’m considering learning swift and using it for my game if i need something more powerful than gdscript for stuff
Awesome
I'm such a fan of Miguel de Icaza, even when I don't agree with him on every detail. And yeah, this could be awesome in Godot.
@@contextfree Hey! Nice to see you here, it seems like you don't use Twitter anymore :(
This talk lets you see a lot of what needs to be improved in C#
Greetings!
@@jonas1ara Yeah, I mostly stopped using Twitter. I should make more videos, though. But yeah, I was skimming through comments here and thought, hey, I know that person! That's always fun.
@@contextfreeAlso want to say nice to see you here 🙏, Just ❤️ the whole knowledge sharing we have in the software engineering community.
Rust (and Zig) get all the attention, but I would argue that Swift is the better long term replacement to languages like C++. I see a lot of people coming to Rust from languages like JavaScript, without some understanding, it is easy to shoot yourself in the foot still with Rust and it is all too easy to write code that is less performant than JavaScript if you don't know what you are doing. Swift is a safer language without sacrificing performance, although you can go lower level to be dangerous.
As someone with a lot of Rust experience that just started with Swift and SwiftUI, I have to disagree.
Swift has a lot of language features that, from a rust perspective, are too powerful. In Swift it takes active discipline to not write spaghetti with computed vars, extensions, DidSet, etc. Inexperienced developers writing Swift are likely not only writing way more buggy code than the equivalent in Rust but the ability to accidentally have thousands of hidden function calls in normal code hidden makes it a candidate for much worse performance.
As for Rust being less safe than Swift or slower than JavaScript, I have genuinely no idea what you’re talking about. That criticism definitely applies to languages like C and C++ where you have to do common tasks manually due to lack of a stable ecosystem, but Rust is fast and safe by default with standard collections and serde and all that.
I like both Rust and Swift quite a lot but I honestly think Rust is a much simpler language in general once you get past finding an async runtime and using the library ecosystem.
@@ilikeshiba
"C and C++ where you have to do common tasks manually due to lack of a stable ecosystem"
I have to disagree.
C and C++ ecosystems are rock solid eternal solutions. They may lack some usability aspects (language-wise or tools-wise) comparing to rust/cargo, but they constantly evolves and there are any library for any programming purpose. And by the way modern C++ has richer standard library (e.g. regex, chrono) than Rust.
MIguel is awesome
This was a great talk. Hope to see more traction with Swift in general. It's a great language imo.
now i feel even more encouraged to just continue with rust
I think DLang gives you good control over the garbage collector.
I still don't get why people complain about the GC performance - what are you doing? using C# like Java or what?
Almost all scripting you do in Godot C# can be done on the stack, with very few dumb exceptions like strings used in dictionaries returned by raycasts
And even that can be worked around easily by creating a primitive-only raycasting method on the native side
What about all the places where you need a temporary collection of something? Didn't think about this one? Someone never worked on a game before.
@@michaelzomsuv3631 ...ever heard of preallocation?
I have more than 15 years of Unity experience. Back in the day when there was no incremental GC to solve the problems for you, the most common way was to allocate the temporary memory you need in advance and reuse it. This is the exact thing they still recommend nowadays for their raycasting implementation by the way, see "Physics.RaycastNonAlloc" in the Unity documentation.
The exact same principle applies to Godot and works well there. And for the rare cases where performance is absolutely critical, you can still use the unsafe context for manual memory management.
Of course you will run into GC problems when creating several megabyte of garbage every frame, but the problem in that case clearly isn't the language, it's the programmer not knowing how to program properly.
@@michaelzomsuv3631 I'm not that good with C# yet, but isn't that exactly what they said? I'm mostly learning by the Microsoft documentation and that makes it very clear how to use the stackalloc keyword for temporary collections on the stack
> Someone never worked on a game before.
Hard to take you seriously when you say ad hominem shit like that.
But you are correct, `new List()` allocates to the heap. In that case, you want to create your lists on startup. You can specify a capacity in the constructor. Annoying, but not that annoying.
It says a lot when Miguel made all his wealth from Microsoft, yet prefers Apple.
he has a company and will push whatever technology his clients want him to push upon Godot.
Swift as a game dev language next to C# and GDScript, yes, absolutely! - but I'm not sold on it being used to build the engine/editor
To me, any argument for Swift seems to map better for Rust in this space - and a big part of that is bolstered by trusting Mozilla with a FOSS language development far more than Apple (at least in regards to priorities for a community outside developers for their own platform)
Swift has much better interoperability with C++ compared to Rust.
I haven't used swift to test that yet, so assuming I completely take your word for it; it also relies on me trusting Apple to support it long term in a way that is suitable to our needs - which is pretty heavily mitigating to any pro you can throw at me tbh
@@eXca1iburN While Apple is a large maintainer of Swift (and currently project lead), it's by far not the only one.
Imagine having a garbage collector that worked properly.
Or barring that, you can just use Swift.
Miguel saying im not a great programmer man :D
Xcode is still very buggy (even on a stock macOS installation), but would be amazing if it worked properly. Still, Swift is an exceptionally nice language.
What are the limitations or downsides of using Swift with Godot?
I am just trying it out and it seems it does not have GDScript interop (yet)
Could you please add chapters to the video?
Miguel seems so salty lately it’s kinda hard to take what he says. Idk whatever fallout happened to him at MS has surely damaged him lol
mmm... I would prefer use Kotlin, or Zig.
I enjoyed listening to this, but it is completely ignores the fact that a computer's memory is in fact constrained and therefore you have to think about a memory allocation strategy in a game that has a lot of content. This won't magically go away with any language in the world.
Also I'm not sure it's the right thing to do to return silently from a function in case something is NULL. If that was an assumption in your application and it gets violated I want to be aware of that and not silently ignore it. I'm not sure these optional types will get us better and more robust programs. The programs may crash less often, but they might still have the same bugs.
I'm not sure what your point is but yes, a computer's memory is always constrained and therefore thinking about memory allocation is important. Contrary to your belief, GC languages like GDScript and C# force you to ignore memory allocation because it's all hidden behind the GC. Because you're concerned about memory allocation, you should actually be using languages like Swift, Rust, or even C++.
The silent return on null is just an example. You're free to do whatever you want when you receive a null, i.e. throw another exception, raise a panic, return default values etc. The improvement is that at least you KNOW whether arguments are nullable or not, and you're forced to handle them during development. Having explicit optional types will definitely make your programs more robust because you won't be discovering accidental null pointer exceptions at runtime.
@@bryanleebmy This was mainly a reply to the section where he says memory allocation patterns are no solutions. Which in my opinion sends wrong signals. I'm by no means a fan of languages like C# for soft realtime applications. I'm just not convinced that switching to another shiny new language will make the problems go away. I think the root of these memory problems is not using appropriate programming techniques. Having a language without GC like C++ doesn't make your memory management magically better. As can be proven by a lot of C++ applications out there.
Why not just add rust on godot instead of swift then?
there are already bindings for rust AFAIK, there's also a vscode addon.
today java gcs are much more sophisticated.. to try to delay ‘stop the world’
Drool ..
More like Linux people lol.
Finished the talk but he never was critical about performance. Swift is a language which is trying to do lots of things to help you, and this is inherently a bad choice for real time graphics. The entire philosophy of Swift is designed for multi-threaded UI based apps.
shit's just sound like discount rust, realtalk.
Nah, crApple tech is not welcome in my world..
That just shows you have the same mindset as an Apple fanboy, except in the other direction.
Imagine going to all this effort to implement yet another shitty, handholding, managed language rather than just teaching people to code properly and design robust systems. The handwave done to dismiss memory pooling was especially egregious.
If you're referring to object pooling, it's not a solution but (to use the analogy in the video) lipstick on a pig.
With regards to "teaching people to code properly", it was already addressed in the talk. No amount of "good practices" and "proper design" can survive time and people. You'll forget your design in 2 months, your new team members won't know your genius, and you'll make mistakes. Why leave these bugs to chance when you can have a compiler handle it for you? It's the reason we built languages like TypeScript, Rust, Kotlin, and Swift.
The better typed and structured your language, the better of a programmer you'll be, because you'll spend less of your effort worrying about trivial issues.
Miguel is an absolute legend in the c#/.net ecosystem, always glad to see him give a talk about something he is passionate about!
I thought tim sweeney was a nice guy. Never met him personally, but never seemed greedy. He respected developers
Likewise. Miguel throwing shots at Tim Sweeney at that venue seems horribly improper, ESPECIALLY after Epic gave Godot a 250,000 dollar grant.
@@deuswulf6193 it's his opinion and he is entitled to it
(also he's 100% right, sweeney's quite an arrogant hypocrite that pursues sinister goals with epic's platform expansion)
@@_remblanc Apparently you haven't heard of the word "decorum". No one said he can't have an opinion, but the time and place for it was improper, especially after Epic donated 250k to Godot's development.
Your colorful attempt to smear Sweeney with highly hyperbolic language says quite a bit about you and the level of bias you have.
You sound like one of those kids online who feel entitled to have everything on steam, and thus adopt some manufactured outrage (and devil figure in Sweeney) in order to affirm said entitlement.
@@_remblanc What sinister goals? And do you have actual proof?
@@encapsulatio it can't be more obvious
Excellent talk