Small correction. cargo update only updates the dependencies in your current project. Its similar to npm update. What you need to do to update your toolchain is rustup update
I mean Tauri and Godot aren't really competitors, though. One is for building games, and the other is for building cross-platform universal applications using a JS/TS frontend + Rust backend. Tauri is an alternative to Electron, not an alternative to Godot. Don't make games in Tauri, and don't make a discord clone in Godot.
Honestly Godot is one of the better ways to develop multiplatform apps. The performance may not be as good as a qt app in c++ but its certainly usable and the Godot editor is made in Godot
Uh, just before I was watching a video about Space Engineers 2 and some people were speculating that the "AE" in the trailer meant After Earth. I almost made a planet Bob joke...
This is awesome! Being able to use Rust inside Godot is more than just "replacing" a scripting language with a system language, it actually provides you a very powerful way of creating projects that require more than just a game. If you are developing anything that needs an official server to play, this is a godsend, imagine writing your server in Rust, and your game in Rust too! Rust is perfect for game servers, and if you make the shared pieces a single project, you can reduce your work by huge amounts! This was the best thing possible for me, developing the server of my game was a big and tedious task, but now it just got 10x easier and faster, I can just reuse the same code for the both the client and server. At the same time, we can still use gdscript for other things, such as player input/output, where it really shines.
@@monkeymango7306 hot reloading is when you can change pieces of your code but dont have to recompile your entire project for every change. This is especially nice for low level languages like Rust or C++ where compilation of bigger projects can easily break 15min
you want `rustup update` to update the toolchain, `cargo update` attempted to update the dependencies which could break if the version constraints aren't sound or a dependency has a semver violation
3.6k forks of Bevy, 36.4k stars. While it's not a drop in replacement of GDScript it's not bad, especially if you wanted to make a game that actually taxes the CPU.
Depends. Any engine calls are a lot slower, pretty much everything else is faster. For general scripting it's not the best solution. For specialized high-performance systems such as custom path finding Rust is fine. At least as long you don't call to many Godot functions...
@@sligit sadly it's a bit more complicated than that, but at least it improved a lot in the 0.2 release. (cached pointers, ClassName rewrite, removable panic hooks, ...) The GDExtension design is very generalized and comes with some annoying performance drawbacks, so it's not really the fault of the godot-rust developers. The C# implementation for example doesn't use GDExtension (yet), making it almost 2x faster than a C/C++ extension when calling the Godot API. GDScript uses a similar approach with some in-engine hacks to speed it up where possible, the language it self is a lot slower though, making it a very bad choice for heavy calculations.
If you learn GDscript you can do amazing things in Godot BUT If you learn Rust (or C or C++ and so on) you can do amazing things in Godot and everywhere else !
@@kubaofc123 well many people started game development from modding of actual games on actual powerful engines, idtech, goldsource, source engine, crytek, all of them use C based languages, python is for web develpment, godot going for a python like language as only option was bad, and this is a win
Old news. Godot wouldn't suffer from Rust bring used in its core (on a fork, of course), in the Godot internal collections, templates, other inner workings. Godot String and StringName would probably work well with the Rust str. However, you wouldn't want to script your game in Rust if you ever wish to finish and release anything. Rust is not a scripting language, it is a systems programming language. And high-level scripting languages are there for a good reason. You should just keep a healthy balance between heavy low-level workloads and high-level logic.
it works really well with bevy, you can introduce scripting where reasonable, but you can develop quite fast with straight rust and some small utilities to tweak during runtime
high level scripting languages almost always never scale well. you end up with companies having to hack together new solutions to make scripting languages scale in terms of readability and managing all the code. not to mention the performance, if you are writing a performance heavy game you will almost always end up rewriting certain parts in a faster language and bind it back to the scripting language. rust also lets you model certain problems really nicely with the algebraic enum types, traits, generics, and borrow checker. it's ultimately up to you, if you enjoy a certain language then you will be more productive than being forced to use a language you dont like
@@lack_of_awareness that might be correct from a pure IT focused perspective. But for anything lets say single-player using rust for the scalability is completely overkill. You don't need to scale well when you only have one instance. In which case LUA, runs fast, small embedable binary, literally has an package to run it in every language imaginable. Is also what is used look at Hades.
@@the_mastermage Great performance (esp. with Lua-to-C JIT compiling) for a scripting language. But on the other hand, Lua's arrays are 1-indexed instead of 0-indexed which makes it prone to user error when interopping or using prior experience from other languages. Are there any uhh...forks of Lua that "fix" that issue?
cool, but why not just stick with Bevy at that point. this way here it's probably very complicated if you don't know much of Godot, and also less performative.
Absolutely love Go, but it truthfully is not really well-suited for game development. I have no objection to it be added, there is already the "godot-go" package, but it might explain the lack of push or interest from anyone to integrate it.
Not going to lie, I'm not interested in using a statically type language with Godot simply because GD script is already amazing imo (and you can configure Godot to force strong typing with GD script if you NEED the type safety and added performance). BUT, if I ever did need to squeeze even more performance and type safety out of my insignificant indie game I would definitely love to have the option to use Go. Say what you want about it not being "suited" towards game development, I love that language and will use it if I can. (And I fail to see how it's any less suited that C#, outside of not having the libraries - which a gd extension would go a step toward improving that).
because you can seamlessly interop with the godot core meaning provide your own classes which have to be performant in rust and do the rest which is whatever in gdscript. if you dont need performance because you have a smaller game you dont really have to use it. not economically sppeaking some people just like rust and gamedev is supposed to be fun if your doing it private :)
Hey my gamedev friend, what is wrong with this "link comments" and deleting it? I love your channel but looking for link at your page is just cumbersome, why not adding them in comment, why deleting tries to make them more accesible?
@@Good_luck_981 I checked it, assuming it was entirely unrelated from how brief you were. That looks like a promising avenue to use Rust in Godot, very small team and users though. Have you tried it yourself, does it run as well as it claims?
golang FFI is not that good, it has big overhead and requires a lot of work to not clash with the go runtime. anytime you need FFI, Go is never the best option, at most it's an alright option. Rust has no overhead when doing FFI and has strong type and null safety, as well as being as performant as C or C++. So if you want performance on a game engine, Rust is the next best alternative if you don't want to use C++ on Godot.
I think Mojo is a better alternative. Similar syntax, better performance. Provides a lower effort transition for users familiar with Python and GDScript.
@ oh true dat, I love mojo. I was just thinking of something fairly performant and pretty simple. I am always worried to do anything with mojo because of its lack of adoption but it would be a good choice as well
ah, the eternal rivalry of rustaceans vs go users (sry I don't know your group name) but this doesn't need to be exclusive at all! GDExt doesn't make accomodations for Rust specifically, pretty sure C bindings already exist, so anyone could just make a go-dot binding. (notwithstanding issues with FFI that I'm not familiar with) And if you do make one, PLEASE name it that, I beg you.
@ I’m not part of a group, I was merely stating that I personally feel like golang would be beneficial for me and most users I would assume due to its more simple nature though I know it’s not as powerful but much less likely to blow off one’s foot. P.S. I petition to have the go users group be the “gogo girls”
I fried my brain trying to make a GDExtension in C++ before. Since then, I have given up on programming in C++. Right now I am working on a ROM for the Nintendo 64 in Rust, and it is going quite smoothly. If I was to try Godot once again, I would do my projects in GDScript and/or Rust.
You wouldn't use this to "script" individual games, you would use it to extend the engine with new nodes and tools (hence "extension") that would normally take long and really ugly looking gdscripts or having to use C++ and all the garbage and pain that entails.
I like both Rust and Godot, and have absolutely no interest in using them together. For all of its strengths, my opinion is that Rust is a terrible language for game development, which exacerbates its weaknesses in addition to nullifying many of its strengths.
If you like Godot, you are probably aware that you can use multiple languages in a single project with it. Then, if there is something for which Rust is good, and you ever need that in a Godot project... Hey, here is an option! Meanwhile, what is Rust not good for that makes it bad for games? Input handling? UI? Graphics? Well, you get to do that with Godot instead. I'm not saying everybody should use this, but I assure you it has uses.
@@Theraot Bevy seems to work quite well for people, even though it's a much newer engine than Godot so it likely has some rougher edges for that reason. Being able to drop down to Rust instead of C++ if you need to optimize something is certainly going to be a blessing. Anyway, the main issue with Rust is the problem with pre-compiled libraries and that's more a problem if you wanted to create a non-open source library so it won't really effect you when using Rust to make a game. Assuming the Godot bindings are solid I honestly can't see a real reason it'd be a problem. Potentially the compile times, but when those start to be a problem you'd be wanting that type safety anyway I'd reckon.
When I saw the thumbnail I was yelling at my screen out of joy. I like the idea of Godot not being basically limited to GDScipt and C# but the problem is that you always have to resort to external editors. Which is fine I guess but I wish that'd change some day. I'm just wondering whether a data oriented language like Rust ist a good fit for an OOP heavy editor like Godot...only the future will tell ig.
Nope, this is basically just a binding for GDnative and GDextension, which has already existed for some years. GDextension allows you to program in C++, Go, Swift, etc... and now Rust as well.
This all leads to the code/libraries being clustered, with people from different stacks unable to fix bugs in other people's code, as if the mess is not big enough already.
@@thegoldenatlas753 Mojo started as closed source for the initial development. It is now partially open source and is planned to become fully open source after it is feature complete. It uses the Apache license.
@@RenderingUser There is no such thing as complete. Just good enough for now. Zig and Mojo dev teams are small. Even a slight uptick in interest and use will accelerate that development significantly. Mojo started as closed to make it easier to manage during the initial development. The same primary dev has a history of successful projects that gives some confidence that it will be "completed" enough for widespread use and then released as open source as explicitly promised. Zig is pretty much already there. Mojo is most of the way there, with the addition of classes the most glaring missing feature on the to do list.
@@stupidburp that seems very much disingenuous. Many have been reluctant to adopt zig for large scale projects due to changes. Only few do. And the few that did literally impacted development of zig. Some language features are missing. It's not even 1.0 yet.
Could you make a video on the recent news that the Rust community has concluded its future lies in integration, interaction, and interconnection with C++?
Tbh, I don't think Rust has much future other than in the sphere of niche languages extolled by cult members. It will never get to be 10% as popular as C++ or even C.
@@squarerootof2 I think the constant blabbering of rust being a language without future and a "cult" is a better sign of those who are ready being part of a cult than the users of rust themselves
🤦♂🤦♂🤦♀Rust as an alternative to GDscript totally defeats its own purpose. The whole point of using GDscript, C# or python, is that you program in a simpler language, with faster compilation, because it's interpreted (compared to C++). Rust is EVEN HARDER to use than C++, and way SLOWER to compile than C++. But using Rust for making low level Godot extensions does make sense, i.e. use Rust for stuff that used to be done in C++. I would rather see the developers just position it as an alternative to GDnative, not GDscript, just be honest and clear about your work.
"Rust is even harder to use than C++" Try using literally any C++ build system, especially SCons which gdextensions use, and see if that holds up lol. Also building is slower because the compiler is actually doing something for you... I agree that it's not an alternative to GDscript though, because you wouldn't use it to prototype scripts you would use it to make concrete new nodes and tools for use in the engine. I think they phrased it that way because people tend to just write whole games in GDscript (or C# scripts) which is cursed but tends to be the case because the alternative is writing an extension. Which is a pain in the ass with C++, but it's way easier in rust with these bindings. Edit: Also not to mention hot reloading means it's not that slow to see your changes in godot...
I disagree with the part of it being harder than C++, which is just not true. Yes the compiler is more strict but most of the time it just flat out tells you what to do
@@blu3260 I'm not advocating for a certain language here, every language has its pros and cons, I just dislike the "alternative to a scripting language" markering. A Build system only sorts out dependencies and prepares stuff for compilation, and it's not inherently linked to a certain language. The exact same could be said about making your own extension, vs binding to an extension; you could have bindings for every language, that's not something that Rust enables. There are already different ways to include C++ into a godot project. On people writing the whole game in a scripting language: that's something you can see everywhere. A lot of people write desktop apps in javascript (with electron and the like). Most people don't know what is happening inside an interpreter or compiler. Most people don't write optimised code. 🤷♂ That's not because they didn't have rust bindings. Rustlang is not a magic fix, it's more like a tool. A compiler does stuff for you, because you tell it what to do (by coding a certain way); if you use stricter coding rules, then a code analyser (build into the compiler) can do more checks. This is true for MISRA-C++ (compared to vanilla C++), and for Rust (compared to C++), and a lot of other cases.
@@gigalodon14 Now, from the perspective of a person being used to writing in a scripting language, that is yet another thing to think about. And no, a compiler doesn't tell you what to do, it's always the other way around. If a compiler throws an error, then it doesn't know what you mean, and doubts your intent, so it asks for clarifications. If a compiler "knew" what to do, then it would just do it by itself. I agree with the people that say it makes more sense to learn C++ first, before learning Rust, to understand and appreciate what Rust is doing.
@ have you ever used rust or the rust compiler? If you get a safety error (which is the big difference here) the compiler literally tells you what line it is on and gives you an example of what you can do
It's a promising project, I've used it some time ago, but it's not really mature enough to be comfortably usable right now. Gd unsoundness been killing me for days.
Here's the list of relatively small tasks where Rust can be useful in Godot: 1. Procedural content generation algorithms: - Perlin noise generation - Random landscape creation - Procedural object placement 2. Mathematical calculations optimization: - Complex motion trajectories - Ballistics calculations - Curve interpolation 3. Data processing: - Parsing large JSON/XML files - Data compression/decompression - Custom save formats 4. Network optimizations: - Data serialization - Packet buffering - Network traffic compression 5. Resource utilities: - File format conversion - Batch image processing - Asset optimization These tasks are quite complex and non-trivial even for an experienced programmer and obviously aren't required in every computer game. In other words, if your game needs to develop a Network traffic compression plugin or Random landscape creation, then you're probably working in a large company rather than being an indie developer, and most likely your company already has a programmer who uses, say, C++.
The problem is that they position it as an alternative to GDscript, not to C++ modules and GD-native/GD-extensions (that already supported Golang, swift, D haxe). They claim that this difficult slow compiling language is an alternative to the quick and easy python-like script, which it's not.
@@epiceric9 Totally agree. Rust itself is a good and useful language, but as you point out, Rust is difficult to learn and slow to compile. GDScript, on the other hand, is very simple and user-friendly. A language where the user doesn't have to specify variable types is the best language to start with. But when I'm savvy enough to understand why I need typing, GDScript lets me use it too. So Rust, C++ and other compiled languages are useful for very specific tasks that most people will never need. An indie developer has enough problems as it is, so I don't think it's necessary to add learning a compiled language to my ever-growing list of tasks.
@@epiceric9 Yes, it is GPT-generated, but it is not garbage. Game development itself is already a very, very complex task, so I need a really good reason to learn one more language. What exactly does Rust offer me as a developer? Do I really need it? For now, my answer is no, I don't need it. Rust and other compiled languages have very specific tasks, such as developing particle systems, advanced physics engines, water simulations, and so on. Rust is hard to learn and slow to compile. For a regular game developer, it seems useless. If you have a different opinion, feel free to share it.
How about GODOT - BASIC , that would be nice. All those programming lenguages Suc*ks to be honest, much blah blahs but just a few can master them, bring human lenguage back
Yea no, Rust is definitely not made with this in mind. Rust is great, but you need to architect around Rust, not Rust around existing systems. To prevent horrible hacks. Too many fundamental issues that clash with each other.
@@squarerootof2Not sure if youtube will freak out about this, it's literally just a famous example of C/C++ but you know. Scary ; float q_rsqrt(float number) { const float threehalfs = 1.5F; float x2 = number * 0.5F; float y = number; // evil floating point bit level hacking long i = *(long*)&y; i = 0x5f3759df - (i >> 1); // what the f***? y = *(float*)&i; y = y * (threehalfs - (x2 * y * y)); return y; }
As a language, Rust is pretty cool. That said, I'm genuinely shocked anyone still supports it, with how the Rust Foundation keeps falling on its own sword with draconian licensing. That said, if you know Rust, this is pretty neat.
thats because the Rust Foundation isnt as crucial as you might think. Never had any influence on me using Rust, so why would I care for crate names or banners online. I'm just here to use the language, thats all...Rust also gets more adoption in the industry by big companies and even they dont seem to care either, support is only gonna get better
Ridiculous. Only 2 languages needed, one for bare metal and one for scripting. Godot needs to choose 2 and stick with it. C still fastest and rust uses more memory than even c++.
Both Mojo and Zig are faster than C and add some modern features. Zig has better integration with existing C projects while Mojo has better performance potential. Zig is more C like in syntax while Mojo is more Python like in syntax.
Urk, godot needs scripting languages, not system languages as bindings I shouldn't have to write a dynamic list type because my binding language is C/Rust/C++/Zig of all things Python is fine
@@DotNetCookbook It doesn't imply anything of the sort. The fate of this extension has nothing to do with whether or not it gets adopted. People will either use it or they won't. The people who created it will either keep maintaining it or they won't. Nothing to do with the Godot devs.
@@DotNetCookbook This is mental numbness at its best, many successful games were literally made with unknown technologies (many which already died), the technology is only the vehicle of the creation, it don't need to survive for the eternity.
@@DotNetCookbook The whole point with GDExtension is to allow people to make extensions without it needing to affect Godot itself. There's literally no reason to doom and gloom an extension.
He already said in a previous video that he won't go into covering the community drama so you'll have to look elsewhere for that. That alternative will likely only make progress if and when they stop pulling progress that Godot has already made.
@@lylicasoelluna6810 the problem is, it is not community drama. you are down playing it. it is a reoccurring problem in the open source dev circles where ppl are gatekeep and select based on political propaganda, not based on merit.
@@foodlfg Then you are mixing things, because that was never about wokeness. I can tell you exactly how it happens: I start an open source project, I'm the only one contributing because nobody cares, right? Eventually I make something people find usable, and some people want to contribute, but I don't trust they will stick around, futhermore as the number of issues and pull requests increase, I find myself overwhelmed, so I become selective with what I accept. Bigger projects can delegate the work, but even in Linux one person has the final say. That is the natural end point of a popular open source project started by an individual. Plus. for the project founders there are reasons to not leave the guard down, because what I described above is a vector of attack: Overwhelm the developers with issues and drama, then send a savior to help, gain the trust of the developers, and a while later put some malicious code in the repository. See all the cases with malware in npm packages for reference. See? That problem you see in open source circles has no wokeness. --- Now, Godot? They suffer from being popular, that brings issues and pull requests. Juan step down (yes, he is still involved) so it is a team that decides what ot merge now. When Juan was deciding he was more strict, yet the team we have now has not been able to clear the list of issues (yet, they are closing tons, you can check the repositories). Since most of the contribution comes from voluntaries (there are more pull requests from third party contributors than from the core team), they have been reluctant to make a roadmap, and with the core team busy... They have communication problem. People don't know what features to expect or what kind of contributions are welcome. For a while they didn't want to run forums or discord (the developers don't want to be moderating), some community members step up to provide some forums and discord, and so the developers pointed people there... And the people used to think they were official. The forum exploted first, that is past drama. The recent drama is a combination of two things: Moderation drama in the unofficial discord, and mistakes made by the community manager, somehow these expoted about the same time. The community manager was hired to aliviate the communication problem I mentioned above, of course. And her posts are the only woke point in this whole thing. And development is still going as usual. I hope I don't need to go over the events of the recent drama, there is plenty of coverage already. But just to be clear, the people that were banned on Github were people opening agry issues. The people that pulled donations barely made a dent on the budget. And, as I said, development is going as usual. Futhermore, Godot remains free and open source, free to use for whatever you want, woke or not... Even for the people banned from posting on Github. What does Godot do with donations? They keep them in a fund to ensure they can guarantee long term job security for their employees. If they didn't, they would burn that money quickly hiring new people, to then not be able to keep them around and that would result in layoffs. And it has been their policy that the few hires they make are from people already contributing to Godot (so they are motivated and have the know-how) and they are hired to work on whatever parts of Godot they want (so they remain motivated). Of course the community manager is not a solution to the ulterior problem. The solution might come form W4games, which - unlike the Godot fundation - will hire - with private investments - directly to develop specific features (aimed first and foremost at networking and console ports), so look for a roadmap from them. That is, W4games will operate outside of the traditional open source modus operandi. Are the third party forks going to be better? Arguebly, since they fork Godot and pull changes, they are strictly not worse. But being 1% better or 2% is only enough for the politically motivated and the dim witted to move to move to them, why? because innertia and uncertainty of future support. That is, people who are working in a long term project don't want to risk migrating. If the forks manage to accelerate and provide something worth migrating to is yet to be seen. As you might know, it is not unusual for forks to die. In theory, there might come a point where they are - say - 10% better than Godot and then people migrate en mass, but we are far from that. You remain free to use whatever you want. Godot, a fork, some unrelated engine, your own, whatever. There is nothing wrong with being politically motivated. And yes, a "no politics" stance is a politics stance.
god nooooo, please. its single one currently "ok" game engine nowadays rusts has Bevy (ecs-ultra-safe-best-game-engine) go use it (i know that its just extension language, but it will make godot dev team very slow)
How would the Godot team slow down from someone using GDExtension? It *literally* doesn't make any sense. The whole point with GDExtension is to allow external teams to make extensions without it affecting the Godot team…
@Sylfa if it will become popular, there will be screams like "we need this in api to make it safe because our rust has different way of thinking and don't match low-level constructs". And godot team should react to this, otherwise rusfans will attack it every where
Key Links
gamefromscratch.com/godot-rust-rust-gdextension-for-godot/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
*BlueSky*: bsky.app/profile/gamefromscratch.bsky.social
-----------------------------------------------------------------------------------------------------------
Small correction. cargo update only updates the dependencies in your current project. Its similar to npm update. What you need to do to update your toolchain is rustup update
This is actually exciting as I have been wanting to make Tauri apps. This is a good way to get familiar with rust.
Why not just use tauri? It's probably easier to use than godot, assuming you know web dev
@@sinsinkun I think it's more of a way to use more Rust, which would also help with their Tauri app endeavours
I mean Tauri and Godot aren't really competitors, though. One is for building games, and the other is for building cross-platform universal applications using a JS/TS frontend + Rust backend. Tauri is an alternative to Electron, not an alternative to Godot. Don't make games in Tauri, and don't make a discord clone in Godot.
Honestly Godot is one of the better ways to develop multiplatform apps. The performance may not be as good as a qt app in c++ but its certainly usable and the Godot editor is made in Godot
"What kind of name is Bob for a planet?" "Well, you don't have to live on Bob."
Uh, just before I was watching a video about Space Engineers 2 and some people were speculating that the "AE" in the trailer meant After Earth. I almost made a planet Bob joke...
Underrated mf film
This is awesome! Being able to use Rust inside Godot is more than just "replacing" a scripting language with a system language, it actually provides you a very powerful way of creating projects that require more than just a game. If you are developing anything that needs an official server to play, this is a godsend, imagine writing your server in Rust, and your game in Rust too! Rust is perfect for game servers, and if you make the shared pieces a single project, you can reduce your work by huge amounts! This was the best thing possible for me, developing the server of my game was a big and tedious task, but now it just got 10x easier and faster, I can just reuse the same code for the both the client and server. At the same time, we can still use gdscript for other things, such as player input/output, where it really shines.
hot reload is not really rust function, it's godot extenstion feature. and previous versions had reload too
what does hot reload do?
@@monkeymango7306 hot reloading is when you can change pieces of your code but dont have to recompile your entire project for every change. This is especially nice for low level languages like Rust or C++ where compilation of bigger projects can easily break 15min
@@monkeymango7306 don't have to restart godot every time u compile gdextension I think
you want `rustup update` to update the toolchain, `cargo update` attempted to update the dependencies which could break if the version constraints aren't sound or a dependency has a semver violation
Any updates on the bevy front?
No games yet. I consider it as a success for Rust game engine, time to create a new one
@@manapotion1594 oh we just lieing now huh? Or did you not see Tiny Glade release and get massive praise?
@@manapotion1594 dude, take your meds, Bevy is also still in heavy development and not a finished engine at all.
was looking at this project just yesterday; very cool.
All 4 rust game devs will be thrilled!
3.6k forks of Bevy, 36.4k stars.
While it's not a drop in replacement of GDScript it's not bad, especially if you wanted to make a game that actually taxes the CPU.
@@Sylfa Ok, all *FIVE* rust game devs will be thrilled!
@@Sylfa >make a game
Dude we don't do that in Rust. Only game engines allowed. Or Rust Foundation gonna sue your ass
🌈 + 🌈 = 🌈🌈
@@manapotion1594 >Tiny Glade enters chat
Maybe we an start using Vulkan APIs and easy libraries to compile GUIs to any platform/architecture.
Massive performance improvements over gdscript?
Most likely
Depends. Any engine calls are a lot slower, pretty much everything else is faster. For general scripting it's not the best solution. For specialized high-performance systems such as custom path finding Rust is fine. At least as long you don't call to many Godot functions...
@@user-iw1gy7ev6e are you sure engine calls are slower? Isn't it just FFI into the C++?
@@user-iw1gy7ev6e If anything it would be bottlenecked down to the C++ level, not the GDScript level though, which is what OP is asking
@@sligit sadly it's a bit more complicated than that, but at least it improved a lot in the 0.2 release. (cached pointers, ClassName rewrite, removable panic hooks, ...)
The GDExtension design is very generalized and comes with some annoying performance drawbacks, so it's not really the fault of the godot-rust developers. The C# implementation for example doesn't use GDExtension (yet), making it almost 2x faster than a C/C++ extension when calling the Godot API.
GDScript uses a similar approach with some in-engine hacks to speed it up where possible, the language it self is a lot slower though, making it a very bad choice for heavy calculations.
geez, people will do anything to avoid GDScript huh... woof
its an awful language derived from another awful language
Sounds like skill issue
If you learn GDscript you can do amazing things in Godot
BUT
If you learn Rust (or C or C++ and so on) you can do amazing things in Godot and everywhere else !
It's useful if you need extra performance and don't want to use C++
@@kubaofc123 well many people started game development from modding of actual games on actual powerful engines, idtech, goldsource, source engine, crytek, all of them use C based languages, python is for web develpment, godot going for a python like language as only option was bad, and this is a win
Old news. Godot wouldn't suffer from Rust bring used in its core (on a fork, of course), in the Godot internal collections, templates, other inner workings. Godot String and StringName would probably work well with the Rust str. However, you wouldn't want to script your game in Rust if you ever wish to finish and release anything. Rust is not a scripting language, it is a systems programming language. And high-level scripting languages are there for a good reason. You should just keep a healthy balance between heavy low-level workloads and high-level logic.
it works really well with bevy, you can introduce scripting where reasonable, but you can develop quite fast with straight rust and some small utilities to tweak during runtime
high level scripting languages almost always never scale well. you end up with companies having to hack together new solutions to make scripting languages scale in terms of readability and managing all the code. not to mention the performance, if you are writing a performance heavy game you will almost always end up rewriting certain parts in a faster language and bind it back to the scripting language.
rust also lets you model certain problems really nicely with the algebraic enum types, traits, generics, and borrow checker.
it's ultimately up to you, if you enjoy a certain language then you will be more productive than being forced to use a language you dont like
@@lack_of_awarenessyeah right this never happens with c and cpp right ?
@@lack_of_awareness that might be correct from a pure IT focused perspective. But for anything lets say single-player using rust for the scalability is completely overkill. You don't need to scale well when you only have one instance. In which case LUA, runs fast, small embedable binary, literally has an package to run it in every language imaginable.
Is also what is used look at Hades.
@@the_mastermage Great performance (esp. with Lua-to-C JIT compiling) for a scripting language. But on the other hand, Lua's arrays are 1-indexed instead of 0-indexed which makes it prone to user error when interopping or using prior experience from other languages.
Are there any uhh...forks of Lua that "fix" that issue?
cool, but why not just stick with Bevy at that point. this way here it's probably very complicated if you don't know much of Godot, and also less performative.
Godot with extra steps
Godot but with a good language
@@Foxtrop13 gdscript, c++ and c# are bad languages ?
@ no buddy is just godot woth extra steps
@@HakaruMedia steps that give you a better language, worthy steps
@@Foxtrop13 why do I think you’re a meat rider right now
4:12 Nothing bad about it, but why did you decide to use the terminal to navigate the project? 😅
So he could do cargo build ;-)
WHY NOT GOlang??
Absolutely love Go, but it truthfully is not really well-suited for game development. I have no objection to it be added, there is already the "godot-go" package, but it might explain the lack of push or interest from anyone to integrate it.
Not going to lie, I'm not interested in using a statically type language with Godot simply because GD script is already amazing imo (and you can configure Godot to force strong typing with GD script if you NEED the type safety and added performance).
BUT, if I ever did need to squeeze even more performance and type safety out of my insignificant indie game I would definitely love to have the option to use Go. Say what you want about it not being "suited" towards game development, I love that language and will use it if I can. (And I fail to see how it's any less suited that C#, outside of not having the libraries - which a gd extension would go a step toward improving that).
Why not both?
Why no browser adblock
Some people just like to suffer I guess xD
Esto no es Lenguaje Visual, paso
Why?
Why not?
That's your problem with it?
because rust
because you can seamlessly interop with the godot core meaning provide your own classes which have to be performant in rust and do the rest which is whatever in gdscript. if you dont need performance because you have a smaller game you dont really have to use it. not economically sppeaking some people just like rust and gamedev is supposed to be fun if your doing it private :)
Because rust bros.
Hey my gamedev friend, what is wrong with this "link comments" and deleting it? I love your channel but looking for link at your page is just cumbersome, why not adding them in comment, why deleting tries to make them more accesible?
Because I get channel strikes if the site linked to ever changes. It's RUclipss idiotic policy
If your comment is ever "Hey creator why did you delete x comment?" The answer is always going to boil down to because YT sucks
@@gamefromscratch Cover -- " Godot Sandbox" Plugin.
@@Good_luck_981 I checked it, assuming it was entirely unrelated from how brief you were.
That looks like a promising avenue to use Rust in Godot, very small team and users though. Have you tried it yourself, does it run as well as it claims?
@Sylfa yes, Early Stage, Lack Of Documation.
fastest click of the west 😎
I feel like golang would be better but that’s just me
golang FFI is not that good, it has big overhead and requires a lot of work to not clash with the go runtime. anytime you need FFI, Go is never the best option, at most it's an alright option.
Rust has no overhead when doing FFI and has strong type and null safety, as well as being as performant as C or C++. So if you want performance on a game engine, Rust is the next best alternative if you don't want to use C++ on Godot.
I think Mojo is a better alternative. Similar syntax, better performance. Provides a lower effort transition for users familiar with Python and GDScript.
@ oh true dat, I love mojo. I was just thinking of something fairly performant and pretty simple. I am always worried to do anything with mojo because of its lack of adoption but it would be a good choice as well
ah, the eternal rivalry of rustaceans vs go users (sry I don't know your group name)
but this doesn't need to be exclusive at all! GDExt doesn't make accomodations for Rust specifically, pretty sure C bindings already exist, so anyone could just make a go-dot binding. (notwithstanding issues with FFI that I'm not familiar with) And if you do make one, PLEASE name it that, I beg you.
@ I’m not part of a group, I was merely stating that I personally feel like golang would be beneficial for me and most users I would assume due to its more simple nature though I know it’s not as powerful but much less likely to blow off one’s foot.
P.S. I petition to have the go users group be the “gogo girls”
To be proud making pride list
Are you telling me it won't be a nightmare to setup this time? I've been meaning to try GDExtension, perhaps I'll try this too.
I fried my brain trying to make a GDExtension in C++ before.
Since then, I have given up on programming in C++.
Right now I am working on a ROM for the Nintendo 64 in Rust, and it is going quite smoothly.
If I was to try Godot once again, I would do my projects in GDScript and/or Rust.
@@OSharraps Lol, I don't believe a word but fantasizing helps some people cope with their dull lives.
@@OSharrapsThat's the winner mentality!
@@squarerootof2 Why would it be impossible to make a N64 ROM in Rust ?
@@squarerootof2 ruclips.net/video/AcbYz4RKQeY/видео.html
You wouldn't use this to "script" individual games, you would use it to extend the engine with new nodes and tools (hence "extension") that would normally take long and really ugly looking gdscripts or having to use C++ and all the garbage and pain that entails.
I like both Rust and Godot, and have absolutely no interest in using them together. For all of its strengths, my opinion is that Rust is a terrible language for game development, which exacerbates its weaknesses in addition to nullifying many of its strengths.
If you like Godot, you are probably aware that you can use multiple languages in a single project with it. Then, if there is something for which Rust is good, and you ever need that in a Godot project... Hey, here is an option! Meanwhile, what is Rust not good for that makes it bad for games? Input handling? UI? Graphics? Well, you get to do that with Godot instead. I'm not saying everybody should use this, but I assure you it has uses.
@@Theraot Bevy seems to work quite well for people, even though it's a much newer engine than Godot so it likely has some rougher edges for that reason. Being able to drop down to Rust instead of C++ if you need to optimize something is certainly going to be a blessing.
Anyway, the main issue with Rust is the problem with pre-compiled libraries and that's more a problem if you wanted to create a non-open source library so it won't really effect you when using Rust to make a game. Assuming the Godot bindings are solid I honestly can't see a real reason it'd be a problem. Potentially the compile times, but when those start to be a problem you'd be wanting that type safety anyway I'd reckon.
Thats cool
If you want Godot with rust, then use Godot with Rust.
Just when I thought I could use another game engine... 😆
When I saw the thumbnail I was yelling at my screen out of joy. I like the idea of Godot not being basically limited to GDScipt and C# but the problem is that you always have to resort to external editors. Which is fine I guess but I wish that'd change some day. I'm just wondering whether a data oriented language like Rust ist a good fit for an OOP heavy editor like Godot...only the future will tell ig.
Nope, this is basically just a binding for GDnative and GDextension, which has already existed for some years.
GDextension allows you to program in C++, Go, Swift, etc... and now Rust as well.
Patiently waiting for Go’lang’dot
This all leads to the code/libraries being clustered, with people from different stacks unable to fix bugs in other people's code, as if the mess is not big enough already.
Welcome to rust in general.
@@tf5pZ9H5vcAdBp , welcome to programming in general.
Welcome to software engineering
Already malding that his slow copium dotnet runtime is losing HAHAHA 🤣
@@RustIsWinning honestly I couldn't care less about your "winning" or "losing". I just want one good open source game engine
Zig and Mojo would be more interesting language options.
Mojo is closed source
I wouldn't touch it with a 50ft pole
@@thegoldenatlas753 Mojo started as closed source for the initial development. It is now partially open source and is planned to become fully open source after it is feature complete. It uses the Apache license.
Mojo is closed, and zig is incomplete
@@RenderingUser There is no such thing as complete. Just good enough for now. Zig and Mojo dev teams are small. Even a slight uptick in interest and use will accelerate that development significantly. Mojo started as closed to make it easier to manage during the initial development. The same primary dev has a history of successful projects that gives some confidence that it will be "completed" enough for widespread use and then released as open source as explicitly promised. Zig is pretty much already there. Mojo is most of the way there, with the addition of classes the most glaring missing feature on the to do list.
@@stupidburp that seems very much disingenuous. Many have been reluctant to adopt zig for large scale projects due to changes. Only few do. And the few that did literally impacted development of zig.
Some language features are missing. It's not even 1.0 yet.
The srsly couldn't name godot strings anything other than gstring? 💀
Rudot
1000th like, just saying.
Could you make a video on the recent news that the Rust community has concluded its future lies in integration, interaction, and interconnection with C++?
Tbh, I don't think Rust has much future other than in the sphere of niche languages extolled by cult members. It will never get to be 10% as popular as C++ or even C.
@@squarerootof2Clueless deluxe about system programming LMAO. Hey why not go back to react and deploy more useless vercel edge function OMEGALUL 😂
@@RustIsWinning Why not link us to your repos so we can admire your contributions, Rustyboi?
@@squarerootof2 I don't need that ego boost tbh. But keep learning what you enjoy because I have nothing against that
@@squarerootof2
I think the constant blabbering of rust being a language without future and a "cult" is a better sign of those who are ready being part of a cult than the users of rust themselves
🤦♂🤦♂🤦♀Rust as an alternative to GDscript totally defeats its own purpose.
The whole point of using GDscript, C# or python, is that you program in a simpler language, with faster compilation, because it's interpreted (compared to C++).
Rust is EVEN HARDER to use than C++, and way SLOWER to compile than C++.
But using Rust for making low level Godot extensions does make sense, i.e. use Rust for stuff that used to be done in C++. I would rather see the developers just position it as an alternative to GDnative, not GDscript, just be honest and clear about your work.
"Rust is even harder to use than C++"
Try using literally any C++ build system, especially SCons which gdextensions use, and see if that holds up lol.
Also building is slower because the compiler is actually doing something for you... I agree that it's not an alternative to GDscript though, because you wouldn't use it to prototype scripts you would use it to make concrete new nodes and tools for use in the engine. I think they phrased it that way because people tend to just write whole games in GDscript (or C# scripts) which is cursed but tends to be the case because the alternative is writing an extension. Which is a pain in the ass with C++, but it's way easier in rust with these bindings.
Edit: Also not to mention hot reloading means it's not that slow to see your changes in godot...
I disagree with the part of it being harder than C++, which is just not true. Yes the compiler is more strict but most of the time it just flat out tells you what to do
@@blu3260 I'm not advocating for a certain language here, every language has its pros and cons, I just dislike the "alternative to a scripting language" markering.
A Build system only sorts out dependencies and prepares stuff for compilation, and it's not inherently linked to a certain language.
The exact same could be said about making your own extension, vs binding to an extension; you could have bindings for every language, that's not something that Rust enables. There are already different ways to include C++ into a godot project.
On people writing the whole game in a scripting language: that's something you can see everywhere. A lot of people write desktop apps in javascript (with electron and the like). Most people don't know what is happening inside an interpreter or compiler. Most people don't write optimised code. 🤷♂ That's not because they didn't have rust bindings.
Rustlang is not a magic fix, it's more like a tool.
A compiler does stuff for you, because you tell it what to do (by coding a certain way); if you use stricter coding rules, then a code analyser (build into the compiler) can do more checks.
This is true for MISRA-C++ (compared to vanilla C++), and for Rust (compared to C++), and a lot of other cases.
@@gigalodon14 Now, from the perspective of a person being used to writing in a scripting language, that is yet another thing to think about.
And no, a compiler doesn't tell you what to do, it's always the other way around.
If a compiler throws an error, then it doesn't know what you mean, and doubts your intent, so it asks for clarifications. If a compiler "knew" what to do, then it would just do it by itself.
I agree with the people that say it makes more sense to learn C++ first, before learning Rust, to understand and appreciate what Rust is doing.
@ have you ever used rust or the rust compiler? If you get a safety error (which is the big difference here) the compiler literally tells you what line it is on and gives you an example of what you can do
It's a promising project, I've used it some time ago, but it's not really mature enough to be comfortably usable right now. Gd unsoundness been killing me for days.
Here's the list of relatively small tasks where Rust can be useful in Godot:
1. Procedural content generation algorithms:
- Perlin noise generation
- Random landscape creation
- Procedural object placement
2. Mathematical calculations optimization:
- Complex motion trajectories
- Ballistics calculations
- Curve interpolation
3. Data processing:
- Parsing large JSON/XML files
- Data compression/decompression
- Custom save formats
4. Network optimizations:
- Data serialization
- Packet buffering
- Network traffic compression
5. Resource utilities:
- File format conversion
- Batch image processing
- Asset optimization
These tasks are quite complex and non-trivial even for an experienced programmer and obviously aren't required in every computer game. In other words, if your game needs to develop a Network traffic compression plugin or Random landscape creation, then you're probably working in a large company rather than being an indie developer, and most likely your company already has a programmer who uses, say, C++.
The problem is that they position it as an alternative to GDscript, not to C++ modules and GD-native/GD-extensions (that already supported Golang, swift, D haxe).
They claim that this difficult slow compiling language is an alternative to the quick and easy python-like script, which it's not.
This comment is just ChatGPT garbage.
@@epiceric9 Totally agree. Rust itself is a good and useful language, but as you point out, Rust is difficult to learn and slow to compile.
GDScript, on the other hand, is very simple and user-friendly. A language where the user doesn't have to specify variable types is the best language to start with. But when I'm savvy enough to understand why I need typing, GDScript lets me use it too.
So Rust, C++ and other compiled languages are useful for very specific tasks that most people will never need. An indie developer has enough problems as it is, so I don't think it's necessary to add learning a compiled language to my ever-growing list of tasks.
@@epiceric9 Yes, it is GPT-generated, but it is not garbage. Game development itself is already a very, very complex task, so I need a really good reason to learn one more language. What exactly does Rust offer me as a developer? Do I really need it? For now, my answer is no, I don't need it. Rust and other compiled languages have very specific tasks, such as developing particle systems, advanced physics engines, water simulations, and so on. Rust is hard to learn and slow to compile. For a regular game developer, it seems useless.
If you have a different opinion, feel free to share it.
I wish I could downvote comments
If you want godot with rust, then use bevy 🌝
Bevy still doesn't have an Editor ;-)
@igorthelight i know, i dont need it 🌝
@@igorthelightMake your own or use external editor
@@Nicholas-nu9jx Fair point but shouldn't Bevy be called a game framework then?
@igorthelight to me it's an engine but incomplete one. It has to many features to be a framework in my opinion
I just wanted to say bringing rust to anything is a bad idea... just use Lua or Go or Julia and call it a day
How about GODOT - BASIC , that would be nice. All those programming lenguages Suc*ks to be honest, much blah blahs but just a few can master them, bring human lenguage back
🎉🎉🤯🎉🎉
Stop it!
I can't take it anymore!
This is too cool 😎
hilarious
the meme storm is coming!
Rust in UE would be awesome
For a while I believe someone wrote a library that let you use a rust engine with unity's renderer. Not quite it, but it's a step
No it wouldn't. Rust sucks
that's fine, just leave godot alone
Yea no, Rust is definitely not made with this in mind. Rust is great, but you need to architect around Rust, not Rust around existing systems. To prevent horrible hacks.
Too many fundamental issues that clash with each other.
@@lunarjournalYourMama sucks. Ask her LOL 😂
two woke-cultured softwares finally found each other.
C++ is better than Rust, btw
pretty cool! but GDScript is pretty good IMO :)
It's good enough for the job and if you want better you learn a bit of C++ and you're fixed.
@@squarerootof2Not sure if youtube will freak out about this, it's literally just a famous example of C/C++ but you know. Scary ;
float q_rsqrt(float number) {
const float threehalfs = 1.5F;
float x2 = number * 0.5F;
float y = number;
// evil floating point bit level hacking
long i = *(long*)&y;
i = 0x5f3759df - (i >> 1); // what the f***?
y = *(float*)&i;
y = y * (threehalfs - (x2 * y * y));
return y;
}
As a language, Rust is pretty cool. That said, I'm genuinely shocked anyone still supports it, with how the Rust Foundation keeps falling on its own sword with draconian licensing. That said, if you know Rust, this is pretty neat.
thats because the Rust Foundation isnt as crucial as you might think. Never had any influence on me using Rust, so why would I care for crate names or banners online. I'm just here to use the language, thats all...Rust also gets more adoption in the industry by big companies and even they dont seem to care either, support is only gonna get better
the "draconian licensing" was just a draft people took wayyyy out of proportions and it's stupid to care anymore
Ridiculous. Only 2 languages needed, one for bare metal and one for scripting. Godot needs to choose 2 and stick with it. C still fastest and rust uses more memory than even c++.
Both Mojo and Zig are faster than C and add some modern features. Zig has better integration with existing C projects while Mojo has better performance potential. Zig is more C like in syntax while Mojo is more Python like in syntax.
rust bindings is community made gdextensions, so not official.
Urk, godot needs scripting languages, not system languages as bindings
I shouldn't have to write a dynamic list type because my binding language is C/Rust/C++/Zig of all things
Python is fine
@@PixelThorn Python is fine, Mojo is better.
Rust is top!
Another gimmick feature to Godot.
There has never been a game engine to successfully and equally support 3+ programming languages for a reason
Godot only supports two languages. Anything else is 3rd party.
@@Gladstone-hk9xw exactly. This implies that either this thing never gets adopted, stays niche and dies OR it gets adopted with would be a bad thing.
@@DotNetCookbook It doesn't imply anything of the sort. The fate of this extension has nothing to do with whether or not it gets adopted. People will either use it or they won't. The people who created it will either keep maintaining it or they won't. Nothing to do with the Godot devs.
@@DotNetCookbook
This is mental numbness at its best, many successful games were literally made with unknown technologies (many which already died), the technology is only the vehicle of the creation, it don't need to survive for the eternity.
@@DotNetCookbook The whole point with GDExtension is to allow people to make extensions without it needing to affect Godot itself. There's literally no reason to doom and gloom an extension.
Bad move, rust is like corona for software.
hopefully it just remains an external extension
First
Hahaha
Horrible 🤣
YourMama is horrible! Ask her 🤣
what about the crazy woke godot dev problem?
what is up with the freed godot alternative?
He already said in a previous video that he won't go into covering the community drama so you'll have to look elsewhere for that.
That alternative will likely only make progress if and when they stop pulling progress that Godot has already made.
You mean the made up twitter drama? Are you dorks really still on that?
@@lylicasoelluna6810 the problem is, it is not community drama. you are down playing it. it is a reoccurring problem in the open source dev circles where ppl are gatekeep and select based on political propaganda, not based on merit.
Take your bait elsewhere moron.
@@foodlfg Then you are mixing things, because that was never about wokeness.
I can tell you exactly how it happens: I start an open source project, I'm the only one contributing because nobody cares, right? Eventually I make something people find usable, and some people want to contribute, but I don't trust they will stick around, futhermore as the number of issues and pull requests increase, I find myself overwhelmed, so I become selective with what I accept. Bigger projects can delegate the work, but even in Linux one person has the final say. That is the natural end point of a popular open source project started by an individual.
Plus. for the project founders there are reasons to not leave the guard down, because what I described above is a vector of attack: Overwhelm the developers with issues and drama, then send a savior to help, gain the trust of the developers, and a while later put some malicious code in the repository. See all the cases with malware in npm packages for reference.
See? That problem you see in open source circles has no wokeness.
---
Now, Godot? They suffer from being popular, that brings issues and pull requests. Juan step down (yes, he is still involved) so it is a team that decides what ot merge now. When Juan was deciding he was more strict, yet the team we have now has not been able to clear the list of issues (yet, they are closing tons, you can check the repositories). Since most of the contribution comes from voluntaries (there are more pull requests from third party contributors than from the core team), they have been reluctant to make a roadmap, and with the core team busy... They have communication problem. People don't know what features to expect or what kind of contributions are welcome. For a while they didn't want to run forums or discord (the developers don't want to be moderating), some community members step up to provide some forums and discord, and so the developers pointed people there... And the people used to think they were official.
The forum exploted first, that is past drama.
The recent drama is a combination of two things: Moderation drama in the unofficial discord, and mistakes made by the community manager, somehow these expoted about the same time. The community manager was hired to aliviate the communication problem I mentioned above, of course. And her posts are the only woke point in this whole thing. And development is still going as usual.
I hope I don't need to go over the events of the recent drama, there is plenty of coverage already. But just to be clear, the people that were banned on Github were people opening agry issues. The people that pulled donations barely made a dent on the budget. And, as I said, development is going as usual. Futhermore, Godot remains free and open source, free to use for whatever you want, woke or not... Even for the people banned from posting on Github.
What does Godot do with donations? They keep them in a fund to ensure they can guarantee long term job security for their employees. If they didn't, they would burn that money quickly hiring new people, to then not be able to keep them around and that would result in layoffs. And it has been their policy that the few hires they make are from people already contributing to Godot (so they are motivated and have the know-how) and they are hired to work on whatever parts of Godot they want (so they remain motivated).
Of course the community manager is not a solution to the ulterior problem. The solution might come form W4games, which - unlike the Godot fundation - will hire - with private investments - directly to develop specific features (aimed first and foremost at networking and console ports), so look for a roadmap from them. That is, W4games will operate outside of the traditional open source modus operandi.
Are the third party forks going to be better? Arguebly, since they fork Godot and pull changes, they are strictly not worse. But being 1% better or 2% is only enough for the politically motivated and the dim witted to move to move to them, why? because innertia and uncertainty of future support. That is, people who are working in a long term project don't want to risk migrating. If the forks manage to accelerate and provide something worth migrating to is yet to be seen. As you might know, it is not unusual for forks to die. In theory, there might come a point where they are - say - 10% better than Godot and then people migrate en mass, but we are far from that.
You remain free to use whatever you want. Godot, a fork, some unrelated engine, your own, whatever. There is nothing wrong with being politically motivated. And yes, a "no politics" stance is a politics stance.
The Great Woke Couple!
TGWC!
💊 👈
A woke com meets another. Additional reason to leave it now!
💊👈
Meds
god nooooo, please. its single one currently "ok" game engine nowadays
rusts has Bevy (ecs-ultra-safe-best-game-engine)
go use it
(i know that its just extension language, but it will make godot dev team very slow)
How would the Godot team slow down from someone using GDExtension?
It *literally* doesn't make any sense. The whole point with GDExtension is to allow external teams to make extensions without it affecting the Godot team…
@Sylfa it's first step of killing engine
@@morglod No. No it literally isn't.
@Sylfa if it will become popular, there will be screams like "we need this in api to make it safe because our rust has different way of thinking and don't match low-level constructs". And godot team should react to this, otherwise rusfans will attack it every where
@@Sylfa Yes, yes
Great! Now we can blame the monstrosity that is Rust for bad gameplay! 🫡