for me, the performance benefit is not really what I care but using static hints it's much easier to find/prevent runtime errors and you get autocomplete which are awesome things
@swydev3 ай бұрын
yeah its nice to have the engine push you in the right direction for sure. the performance benefits definitely don't hurt though! it's really great that you can get both at the same time!
@scotmcpherson3 ай бұрын
100%, I use type hints everywhere.
@keithwinget6521Ай бұрын
I came here to say this, but you already did!
@americoperez8103 ай бұрын
Something you didn't mention in your video, but i think is equally just as important, is the developer experience when working with statically typed variables. Using statically typed variables allows Godots autocomple to work WAAAAY better, helping the developer write better, less buggy code. For example, if you create your own class with its own functions and properties, the autocomplete will not show you those things sometimes unless you use static typing (in combination with type casting sometimes)
@swydev3 ай бұрын
Great point! Autocomplete is so nice when it works! Thanks for watching!
@mupmuptv3 ай бұрын
Once you get into static typing, you never go back
@swydev3 ай бұрын
lol it’s good to have good habits I suppose ;) thanks for watching!
@Uhfgood2 ай бұрын
It used to be how most programming languages worked.
@TwoThreeFour3 ай бұрын
Static type in general programming is very recommended. It helps the compiler a lot when generating and optimizing the machine code (assembly) and resulting generally better execution as well.
@swydev3 ай бұрын
Yeah it’s an easy way to add some optimizations. The effort vs reward definitely seems worth it. Thanks for watching!
@Zlorak2 ай бұрын
Static typing is not really for the speed, but to help write organized code and to pinpoint bugs faster. Like someone said, once you use it and understand why, you never go back.
@aqua-bery3 ай бұрын
That's it, *statically types your dynamic programming language*
@NoSoyMako3 ай бұрын
for me, I just love how static type is waaay more readable, look at this func test(a, b): return a + b now using types: func test(a:float, b:float)->float: return a+b
@swydev3 ай бұрын
Yeah it definitely makes it easier to see what’s going on! Thanks for watching!
@panik23423 ай бұрын
Performance improvements are a nice plus, but the real advantage of types is documentation. Especially when working in a team, using a dynamically typed language is a recipe for disaster in the long run. The type checker goes not away by using a dynamically typed language. The type checker is now you. So you will have cognitive overhead and have to reverse engineer the code base when you don't have types and come back to your project 6 months later. The best example would be add_address(user) vs add_address(user: User): User. With the second function, you will see on the first glance that the function will take a User and return a User. You can jump to the definition with your editor/IDE of choice, to see what a User actually is. With the first function, you will have to read the code and usages to get a clue what's going on. So besides cognitive overhead you have to have good documentation, which has to be revisited on refactoring and to be honest, documentation will diverge with the code, when time passes.
@swydev3 ай бұрын
great points! documentation can be such a slog! i also really enjoy well-commented code when working with a team.
@comradecid3 ай бұрын
i'm fascinated by this, given that i've never seen anyone ever actually run stats for static typing's effect on compilation/performance. for the benefit of the audience, what i would love to have seen would have been a brief explanation of why there is a performance increase. the increase arises from the fact that the compiler has to 'figure out' the type of every variable used in a codebase, and then allocate the corresponding type/memory, before then performing any calculations using those variables. and then those calculations need to be validated against its initial guesses, before it goes back and corrects them as needed. this is a lot of complex, time-consuming work that happens mainly during initial parsing/compilation, but also partially at runtime. by clearly indicating to the compiler what your intent is, and then reliably sticking with that intent, it removes this unnecessary work, and thus dramatically reduces processing time.
@swydev3 ай бұрын
great points! it makes total sense that requiring less of the compiler would lead to increased performance. i was surprised to see that using := vs explicitly defining the datatype like var myVar : float = 0.1 didn't seem to make a difference even though it would force the compiler to guess the type when the variable was first defined, but i guess it would be negligible compared to actually overwriting the variable or running calculations multiple times
@comradecid3 ай бұрын
@@swydev aye honestly it surprises me, too. between persistent suspicion over this, the clarity provided by explicit typing (var foo: String), and following years of working on shared codebases in professional teams, i never use := and instead just type everything out (var foo: String). it's a pain, but benefits you in the long run, and becomes more or less reflexive after a while.
@skellien2 ай бұрын
Hey guys, if you keep forgetting to static type your variables (or just want godot to yell at you), there's a project setting in the Debug > GDScript > Untyped Declaration option to change into Error. Hope this helps~ p.s: funcs also need to be type declared like, func example() -> void:
@Uhfgood2 ай бұрын
Good to know, at least it's what I'm more familiar with coming from other languages.
@Amonimus2 ай бұрын
Bonus: it's just more convenient for self-documentation, and Godot can autocomplete functions for you if you tell explicitly which class/type is put into a variable.
@koldwen10 күн бұрын
The main reason static typing is preferable to dynamic typing is that it makes the code more scalable and safer overall. You don't have to worry about mixing values in a variable, as it’s restricted to a single type (this is a blessing while debugging). The autocomplete also works way better this way. Even if you're working on a small project and think you might not need static typing, it’s better to use it in case you decide to continue working on that project or it becomes more complex than expected. There’s simply no good reason to choose dynamic typing over static, aside from "b-but it saves me a few seconds sometimes...". I would only choose dynamic if there's a deadline (Game Jams) and those few seconds are actually really needed, or if I'm prototyping something I know I will change.
@adiveler3 ай бұрын
For someone who originally learned programming from languages such as C# and Java - Static typing just feels more right for me!
@swydev3 ай бұрын
go with what you know! thanks for watching!
@CaughtByYourself3 ай бұрын
Hey swydev, I was on a business trip and couldn't verify the impact instantly, that's the reason I didn't reply yet. Was going tonreply and saw this video, hehe😅 No need to blur the name, but thanks that you did without showing clear name without asking! I also wanted to mention that the line counters indicate if all values are statically known for godot or not. Green line indicator means better performance than grey. This indicator was introduced witj 4.x i think.
@swydev3 ай бұрын
Nice! Yeah no worries I figured I was curious so I’d go ahead and test it out! Appreciate you pointing it out!
@CaughtByYourself3 ай бұрын
@@swydev is definitely great, having real numbers to back it up now 👌
@arutonee54343 ай бұрын
In my opinion, the performance of static vs. dynamic typing does not matter, even in the high-performance context of a game. 99.9% of the time, the performance bottleneck comes from an inefficient implementation, never the language itself being slow. The biggest benefit of static typing in my eyes is the ability to implicitly assert the type of a variable and ensure that it will not change. It makes bugs in the form of accidental redefinition and misspelled variables more likely to be caught earlier in the call stack, it helps make common programming idioms easier to notice, as you do not ever have to worry about the type of a given variable changing, and you won't ever have to do explicit type assertion in your functions.
@swydev3 ай бұрын
Great points! Benefits are benefits - cutting dev time down by having more clear code can boost a project in so many ways! Thanks for watching!
@wukerplank3 ай бұрын
Not to mention the warm fuzzy feeling of compile time safety 🥰 One question I have in my mind: With := Godot still has to do type inference (guessing the type, as you called it). Would declaring the type (var health: float = 50.0) be even more efficient?
@swydev3 ай бұрын
I played with that and didn’t see a difference. There may be one but since the variable is only defined once it seems insignificant.
@arashikou66613 ай бұрын
Not a Godot internals expert, but at a guess: While a type does have to be inferred when using := , that inference happens once when the script is compiled. After that, the type remains static and doesn’t have to be inferred every time you run the code. So the performance cost is paid before your game is even running.
@HakanBacon3 ай бұрын
Dang, you got a new subscriber
@swydev3 ай бұрын
Let’s go! Thanks for watching!
@TheSlimHim3 ай бұрын
I also like to use it as it allows for better type hinting in the ide and if I forget the type of a var and do something silly, it throws an error.
@swydev3 ай бұрын
Yeah better autocomplete is always nice! Thanks for watching!
@TokisanGames3 ай бұрын
Static typing isn't used for performance, it's used to catch errors at compile time instead of runtime. I mandate for my team, the only time := is used is if the type is named immediately after. Eg var v:= Vector3(0,0,0). Otherwise we always use the full format for code readability. Eg var v: float = 1.0. You won't see a significant performance boost unless your code is bound by GDScript, which it should not be if you're programming optimally. Your GDScript should be mostly event driven, pushing the work onto the engine. If your game is GDScript bound, static typing is only a bandaid for poor design. Greater improvements will come from restructuring your code.
@swydev3 ай бұрын
Great points! Thanks for sharing! So are you using C# for most things then? What’s the advantage of mixing languages vs abandoning gdscript for a faster language all together?
@TokisanGames3 ай бұрын
@@swydev We use GDScript for Out of the Ashes. 18k lines of code sans addons, blanks, shaders, and comments. And C++ for Terrain3D. There's no need for C# since we've pushed the work onto the engine. I'd only recommend it if it's the language of choice. Our performance is limited by the renderer, and VRAM, not GDScript.
@swydev3 ай бұрын
@TokisanGames very cool. I’ll admit after using Unity, good terrain tools has been something I’ve missed in godot. If you have a dev log or write up on how you’ve handled it I’d be really interested to check it out!
@TokisanGames3 ай бұрын
@@swydev I'm not sure what you mean unless you haven't heard of Terrain3D. This is a C++ Godot addon we released a year ago. I've produced 3 videos on how it works on my channel. Some say it's better than Unity tools, but I haven't used them so can't compare.
@swydev3 ай бұрын
@@TokisanGames ah yeah i've heard of it! didn't realize you were the team behind it! that's awesome! I thought you were referring to using C++ for procedural terrain generation or something to that effect.
@Weahl3 ай бұрын
Wow, that was really interesting, I thought the impact in performance would ve minimal. Thanks for this video! ❤
@swydev3 ай бұрын
Yeah I was surprised as well! We're really only talking about milliseconds here, but it all adds up! Thanks for watching!
@RexSacriticulus2 ай бұрын
There's no actual static typing in GDScript, just type locking. Any piece of data is technically a Variant.
@swydev2 ай бұрын
How do you distinguish between static typing and type locking?
@RexSacriticulus2 ай бұрын
Static typing is about normal data allocation where you allocate a 32-bit integer - you get a 32-bit integer. Dynamic typing or duck typing is about using one universal compound data type (e.g. Any in Python) that switches between modes. This data type has one fixed size of at least 64 bits. For example, you cannot allocate 8192 bytes of total size of 65536 bits, you can only allocate 8192 wildcards that will act as bytes and will occupy at least 8 times as much memory. GDScript communicates with the engine through bindings. When you call a bound low-level function, you pass the wildcard type data as the arguments and receive the returning data as that type too, which creates certain overhead. Type locking is simply the wildcard data type mode switch restriction.
@jimmio37272 ай бұрын
@@swydev Static typing -- type doesn't change and underlying data format is the type. type locking -- type doesn't change and underlying data format is some universal wrapper that has different modes representing the different types. I tried to sum up Rex's answer a bit more but he's got it aside from the part about not being able to allocate exact amounts of memory. It'll end up being slightly larger for the Variant overhead, but because there's built-in packed array types, it's not going to occupy 8x the memory to get 8192 bytes in a contiguous array. It would if they were all separate objects; maybe that's what he was referring to.
@ArturoAlberoАй бұрын
Not only the performance is better, but also the autocompletion and the legibility of the code. Actually, I don't think you should use dynamic type at all, it is much more prone to error and it allows clumsier programming (which is a problem in the long run). And, as you said, it's just a ":" for the simpler and more used types. In Godot, however, the first approach was dynamic typing because GDS is based on python (a dynamic typing language). The static typing was implemented for Godot 4 (I think), that's why some documentation does not use static typing.
@GlitchedCode3 ай бұрын
To note here, you could have static typed your for loop as well for i: int in range(LOOPS) Not sure how much this would have affected the outcome, but something to point out You can also tell your function what to expect to be returned with -> type before the colon when declaring a function. For example func _process(delta: float) -> void: void means to expect nothing to be returned but you can easily replace this with another data type for example -> float -> int -> Vector2 and so on. Just two more things to share
@swydev3 ай бұрын
Great point! Thanks for sharing! Now I’m curious what kind of impact that would have lol
@Vodboi3 ай бұрын
I feel like this video is missing the entire point of statically typed languages. It's mainly about type safety, and makes it a lot easier to keep track of what functions and operations you should be allowed to perform with your variables. I find this especially useful when variables can be transferred across different scripts, like in functions and signals. Also makes writing code easier with autocomplete suggestions.
@swydev3 ай бұрын
It definitely makes code easier to read and maintain. I was curious mostly of what performance impacts there would be when using static typing vs not. As it turns out, while being helpful during development, static types can also positively impact end user experience in a way that better variable names or proper commenting habits can’t.
@ozgurkalay75793 ай бұрын
Better way for a lot of reasons is to specify the type. Eg: var health: int var velocity: Vector2 func get_health() -> int: return health func get_velocity() -> Vector2: return velocity
@swydev3 ай бұрын
yeah i didn't cover typing functions here, but I'm curious what the advantages are to using var health : int = 100 vs var health := 100. In my tests, they were the same performance-wise - what other benefits are there to explicitly typing them like that vs using the := shorthand in your experience?
@AlexanderKoch843 ай бұрын
@@swydev There is none from the pure functional standpoint. The only difference is that it's more readable, expressive and consistent. If for instance you have something like: var stuff := some_function(param1, param2) You have no clue which type the function returns unless you look it up which can become quite tedious over time. And for function parameter definition there is actually no way around that to specify them with name : type syntax. So in order to have better readable and consistent code it'd be better to just stick with one syntax to express static types. At least in my opinion this makes it easier to read and understand.
@swydev3 ай бұрын
@@AlexanderKoch84 great points! Having readable code can have so many benefits even working solo. I appreciate you sharing your knowledge. I’d imagine that there could be an argument made that having more readable code encourages more you to write performant code inherently also - so a double benefit to using static typing given the technical performance enhancements paired with better code overall.
@AlexanderKoch843 ай бұрын
@@swydev That's the beauty of static typing in a (by default) dynamically typed language. It's not just more readable but also faster. Usually performance optimizations - especially the tricky ones - come with the drawback of more complex and harder to understand code but in this case it's combining better readability with faster execution - win-win 😁
@baptistevillain1482 ай бұрын
As a java engineer during the day, my brain could not code without it. Now I discover that it even makes the game faster, great!
@swydev2 ай бұрын
Thanks for watching!
@AnkobiaStudios-bs4vg3 ай бұрын
Im finally sold. My small game just happens to run 1m computations (3D procedural dungeon). And yeah it's slow. But now it can be 20% faster than slow!
@swydev3 ай бұрын
Nice! Lol every little bit helps when you have a lot going on
@Dr.Bamboo-dev2 ай бұрын
I wasn't actually aware of the performance benefit. I use static typing so that I can avoid bugs and easily identify mistakes when I forget what data type I need.
@MrFoof823 ай бұрын
Another consideration is if your end user is on mobile on anything with a battery such as a laptop. The less work the computer is doing, the better the battery life.
@swydev3 ай бұрын
great point! i can't stand it when one app eats up all my battery! :) thanks for watching!
@GamedevDen3 ай бұрын
Faster or not, static typing is the way to go. This helps you prevent bugs and unknown errors later down the line. Take your example of an int becoming a float later in the code; sure, it could be handy in a certain situation, but in that case, change the underlying type. Imagine you're creating a grid system, and use ints for the position. It would be strange if you suddenly got a bug where the grid position is 6.423 no? That is the strength of static typing, as it makes that impossible. (Not hating on the video, just a little comment :D)
@swydev3 ай бұрын
Great points! Static typing can definitely be the equivalent of using bumpers at the bowling alley. It will force your code to adhere to the rules. In almost all cases this is a good thing. Do you have to use it to avoid bugs? Certainly not, but it doesn’t hurt. Looking at performance was interesting to me because it’s directly related to the end user experience by allowing your game to run better on more devices regardless of dev habits, experience, team size, etc. Thanks for watching and sharing your thoughts!
@_gamma.3 ай бұрын
The walrus operator!
@swydev3 ай бұрын
lol i love it! ;)
@stintav3 ай бұрын
I just can't look at "var dookie=1", I love typing "var dookie: int = 1
@swydev3 ай бұрын
🤣
@MrXlee19673 ай бұрын
Hi as a complete beginner to programming, how does one learn static typing from the get go? Is it the same as oop? Should I start with gdscript or python? Or something else. I don't have a galaxy brain 😁
@AlexanderKoch843 ай бұрын
Start with the basics and work your way up to understanding the concepts when you need it. Try to apply what you learned and always critically raise the question for yourself: "There must be a easier/better way to do this". With that you'll get better and more knowledgeable over time. Don't stress yourself out that there are a lot of concepts, languages out there you don't know yet and don't try to get everything at once with falling into the tutorial hell. Just start small, apply what you already know and learn new stuff on the side to improve. I presume you're interested in gamedev and godot by clicking on this vid so that'd be a good starting point. There are a lot of "how to start a simple xy in godot" videos out there - pick one up which is of interest to you, follow it through and don't just copy+paste everything but rather try to understand what it actually does - that would already be a good foundation to work with and later when you have the basics you can dip into more complex topics like dyanmic vs. static typing, oop and other concepts. Hope that helps and good luck on your journey ;-)
@swydev3 ай бұрын
This is fantastic ;)
@swydev3 ай бұрын
To add to Alexander’s reply, I agree godot is a great starting point. Working in a game engine can help you understand what the code does more readily than learning a language solely to learn the language. I find it easier to learn something new by building an actual project vs doing scripting exercises.
@sebastercats61233 ай бұрын
I am in the same scenario too, I always watch these videos to know how "advanced" programming works but never really understand them since I'm a beginner. The basic thought process is that when you encounter a problem or better implementation in your coding journey, informational videos will be the go-to. The problem is that you don't know *when* this kind of coding advice will become useful in your own code. So, information like this is kinda useless without probably intermediate coding knowledge or extensive previous experience. So I always just watch these videos for possible future reference.
@kevinscales3 ай бұрын
@@sebastercats6123 Experience is your guide. If you don't know why a concept would be useful from a brief explanation, you probably don't need to know it yet (some things are more fundamental and are worth learning as soon as you can, but may not be necessary to make stuff work), write more code, figure out the differences between the various ways of doing things that you do know. Experiment and have fun whenever you can with simple projects.
@Mohandas.Gandhi2 ай бұрын
Sick 2j though
@marclurr3 ай бұрын
There's almost no reason to ever use dynamically typed variables. There's never a good reason to change the type of a variable after it's defined.
@swydev3 ай бұрын
what are your thoughts on using dynamically typed methods for polymorphism?
@marclurr3 ай бұрын
@swydev not really sure I know what you mean. An example might help. But in general I'm against changing the meaning of a variable/ method after definition. So if you mean you'd like to swap in functions with a completely different set of parameters or return type, I'd definitely advise against that, mostly in the interest of programmer sanity:)
@swydev3 ай бұрын
An example would be if you had a method to perform some sort of math, for example it might add two numbers together and you wanted it to work for floats or integers. By statically typing the method, you could only ever return one or the other (float or integer) and would need 2 functions for the same task. A dynamically typed method could use the same code regardless of what data type was passed in and return a value in the same data type supplied
@marclurr3 ай бұрын
@swydev fair enough I seewhat you mean. In that case I'd prefer to use a common super type, i.e. number, if available. If that didn't exist then the options are either have overloaded versions, which would require every possible combination of types you want to support, or untyped parameters, which are probably your best option. Touché ;)
@Uhfgood2 ай бұрын
Well imagine my confusion coming from a Pascal background where := means something entirely different :-) -- Honestly I don't know why dynamic typing is a thing anyways. As you showed not only is it slower, but you might be more prone to errors if you're just making types anyways. I understand, for instance, if you're using an integer for a state machine, you might want to make it more explicit by later changing it to a string, however changing a variable definition to use a different type is not really that hard, and even in here it's almost too easy. The only thing is I might would recommend against the := because you may forget, and in some cases not even remember that you made it a static type. Might be a better deal to just do it long hand var myVar : string = "hello"
@vonbluhm72012 ай бұрын
Pascal is one of those languages that feels quite strongly about you defining variable types in advance, lest it won't compile your code at all.
@UhfgoodАй бұрын
@@vonbluhm7201 - Partly why I like it.
@mudscuffer2 ай бұрын
Accurate benchmarking and profiling is more complex than the very simplistic code you showed. For example, for most scripting languages you'll want to exclude outliers caused by garbage collection. Not to mention that micro-benchmarks like yours that show 20% improvement may well have negligible impact on more realistic code. That said, static typing all the way for me, I would not go back to dynamic typing for anything more than 10 lines of code.
@swydev2 ай бұрын
Thanks for watching and sharing your thoughts!
@UndeadFC3 ай бұрын
Can you make tutorial about shop system
@swydev3 ай бұрын
Got it on the list! Thanks for watching!
@carminator123 ай бұрын
Very interesting thanks.
@swydev3 ай бұрын
Thanks for watching!
@TRUFANATIC3 ай бұрын
wow, thats cool, but sometimes you want to keep dynamic type, for instance - collider of raycast3d
@swydev3 ай бұрын
Yeah it’s nice to have the flexibility for sure. Thanks for watching!
@Robnoxious773 ай бұрын
if it’s that simple, it begs the question: why doesn’t the language always put the colon in by default, aka, under the hood, = just always equals := ? There must be a reason it’s seperate, other than just something benign like “it only works with simple types”
@swydev3 ай бұрын
Great question! Wondered that too. I’m not sure I know the answer though lol possibly because it’s built as a wrapper to another language like C++ or maybe a design decision in case a dev has a valid use case where they would change the type later in their code?
@swydev3 ай бұрын
I did a little reading and discovered you can actually force strict typing in the editor under Project Settings -> Debug -> GDScript -> Unassigned Variable if you have Advanced Settings enabled. Doesn't make it happen by default, but you can set it to warn you or throw an error if you need a push to remember to use it.
@petert51943 ай бұрын
Sometimes, you want to keep things in a dynamic type because some later code might attempt to change the value to a different type. If the type was static, things would break at that point. Most dynamic languages (e.g. Python) take the approach that allowing this is better than crashing.
@AlexanderKoch843 ай бұрын
Having enforced static types would break legacy code and code examples/tutorials. The whole idea behind dynamic types is that you can change the type later. As a simple example you start our with a variable "health=10" but later you want to substract 0.1 for hits. With enforced static types this would be a mess (most likely having an implicit float cast for the operation and when assigning cutoff which results in 9 instead of 9.9). Adding these kind of features and optimizations at a later stage (static typing) always comes with the caveat that you need to stay compatible with existing code which brings us to the explicit way to declare it to make it clear and expressive. And as others have already pointed out you can set this up in the editor to warn you about non-static types in the code, which I'm personally also using to keep things tidy and fast.
@generrosity3 ай бұрын
WOW actual stats! But, now my brain wonders about strings, and functions and function returns.... And if Godot does the Java trick I've heard about called inline functions? (As in the performance drop for splitting your functions toooo much) 😅 Yea it doesn't matter for most code. Cool preso!
@swydev3 ай бұрын
Yeah all the little stuff adds up! Thanks for watching!
@JuhoSprite2 ай бұрын
I use c=3 it works much better
@ManjaDev3 ай бұрын
Godot Mono Still Faster btw
@swydev3 ай бұрын
Do you know if mono is faster using GDScript? or only if you're using C#?