GOBOT LANGUAGE LICENSE
The only reason we did not want to go this route in the past was due to license restrictions, but this ceased to be a problem a few months ago when Microsoft acquired Xamarin and relicensed Mono under the MIT license. As a result, it should integrate smoothly into Godot. Truth is that Mono is very well made, has excellent, modern binding extensions (the complete opposite to Java/JNI) and supports multi-threading just fine. In the case of C#, there is a huge amount of love towards this programming language, which is expected due to the main designer being the same guy who created Object Pascal (which was very popular in the 90s with Borland Pascal and later through Delphi). That's why we are working on the support of C# and visual scripting for the upcoming Godot 2.2. Why other languages, then?Įven though we will always recommend new users to go the GDScript route, because we know it's the least hassle option, we understand that developers have different needs and experiences, and that believing in "one size fits all" is a mistake. We tried, we became experts at it, but it just didn't work out.īecause of this, GDScript will always be the main supported language, and our recommended choice for all Godot users. None of this could have been made with a third party language.
GOBOT LANGUAGE CODE
When users write code in GDScript within the IDE, everything simply "just works" and you have the added value of live code completion.
![gobot language gobot language](https://image.slidesharecdn.com/googledevconf2015-150322073523-conversion-gate01/95/gobot-meets-iot-using-the-go-programming-language-to-control-the-things-around-us-12-638.jpg)
GDScript was born as a way to make all these problems go away. Added to that, we could never completely eliminate the stalls related to the garbage collector. True multi-threading (with a stack per thread, but sharing memory) was not supported, and vector types had to be created with custom userpointers, which provided much slower performance than built-in types. Binding code was always large, complex and prone to bugs. Unfortunately, we had many problems with those languages. We understood that most of the code written for a game is not performance critical, and that the C++ part of the engine already covers most of the critical parts, so we originally went for Lua, and then for Squirrel (while trying Python in the process). When we originally made Godot, we were completely certain that we wanted our main scripting language to be dynamically typed due to the high accessibility this provides. This was the case of third party scripting languages such as Lua, Python, Squirrel, etc. is very popular, it does not satisfy our needs. The reality is that we are extremely demanding with our requirements from third party solutions and it just happens that very often, even if a library, language, etc. This could not be further away from the truth. There is a common misundertanding about us in the industry: Godot devs, always trying to reinvent the wheel because we like it. News Why more languages, isn't GDScript enough?