 |
Attention | Topic was automatically imported from the old Question2Answer platform. |
 |
Asked By | DimitriyPS |
 |
Old Version | Published before Godot 3 was released. |
I read the news. I am concerned one fact:
In the Godot community, we all love waiting. Waiting for Vulkan, waiting for WebAssembly, waiting for C#
Does this mean that in the future, Godot on Linux will depend on “Mono”?
|
Reply From: | Calinou |
Mono seems to be MIT-licensed now, for the runtime parts. This means that we are legally able to use it. There also is CoreCLR, though I’m not sure if it can replace Mono in our case.
That said, GDScript may eventually get a static typing option, which would allow for better performance.
Other things to expect in 2.1 and 3.0 might be:
You have not correctly understood. Personally, I don’t need “Mono”. On the contrary, I do not support “Mono” in Linux. I think it is a “foreign body” and I delete it immediately after installing Linux. I know that as do many.
A distinct advantage of the Godot - his exceptional native character for Linux. In news indicated that it is expected “C#”, for Linux it is “Mono”. I believe that the emergence of such dependence in the future - will reduce the attractiveness of the Godot for Linux users.
DimitriyPS | 2016-05-10 14:10
Love the idea of “fly camera” building in 3d is more work than it should be because of the current camera system.
SupToasty | 2016-05-10 16:59
I really want C# support !!
concept of encapsulation and static type will boost the productivity
eaglecat | 2016-05-11 05:34
I am not a principled opponent of C#, just the Godot it cross platform. In the Windows, interpreter “.net” - an inseparable part of the system. On other platforms, the interpreter is “Mono” - this is a very large and useless dependence. Programs “Mono” are regarded as not native. Often, users (e.g. Linux) prefer to remove “Mono”.
DimitriyPS | 2016-05-11 08:53
@eaglecat: If you want visibility modifiers and static typing then ask for those two features. Asking for C# because of those features is like uninstalling your virus scanner because you don’t like its icon.
Of all the languages I know C# is most overloaded with features and paradigms. No matter what you do in C# there’s always at least two different ways of doing it. This leads to less readable code which in turn leads to people posting magic code so you can “solve” your problems by copy-pasting.
I assume you are actually asking for visibility modifiers, because Godot is already better at enforcing encapsulation than Unity for example, which can easily be used in a very procedural way (which is very common in tutorials or code snippets you see on the internet).
One of the main strengths I see in Godot is the clean code base. The downloads are tiny and building it yourself is really easy.
The separation between GDScript and C++ is also very clean. If you need a more powerful language, e.g. so you can access new libraries, then it’s easy enough to write new C++ modules. If you don’t need that power you should be thankful for not having it, because if you intend to write good code every option is a decision you have to make.
Imho supporting Haxe would be a much better choice. That language has three visibility modifiers (unlike C# which has 5) and is type safe using type inference, i.e. it’s type safe but you can still use “var” in almost every place, as long as the type of the variable is recognizable at some point. But unlike C# it has a much more restricted feature set.
But the main issue I see is that it’s probably not a good idea to introduce a general purpose language as an in-editor language. GDScript is a DSL (domain specific language), and that is what makes it so powerful. For example it doesn’t support static members, which may seem weird since it supports static methods, but that facilitates multithreading because it’s much easier to tell which methods access the same nodes. I have to admit that I haven’t looked into the corresponding engine code yet, but that’s how the decision is justified, and that’s the kind of decision you can actually make with a DSL.
The result is that “the way to do it in GDScript” and “the way to do it in Godot” become the same thing. The language can facilitate the right way and make the wrong way less visible. In Unity there’s a huge difference between “the way to do it in C#” and “the way to do it in Unity”, because some things are just implemented in a way that is not really natural to C#.
Warlaan | 2016-05-17 09:03
Personally I, DBScript completely satisfied.
Before I began to study the Godot I was programming on FPC+Lazarus.
I immediately realized that to start learning the Godot - need DBScript. DBScript is not similar to Pascal, so at first I was a little afraid. But to my surprise he “succumbed” is quite easy. I don’t know all the available function and the classes topology but thanks to the documentation I am quite cope with current tasks. Sometimes asking questions here )))
Why I raised the question of C#? I really like the Godot. I was very pleased with the appearance of a full games development environment under Linux (native Linux). When I read in the news that Godot is expected to support C# - I was concerned about it. I don’t wish that the development environment Godot depended on “Mono”.
DimitriyPS | 2016-05-18 08:59
My advice … Improve GDScript, with new libraries, change in Python 2.7 Python 3.x. As new language I’d like Javascript, there are many libraries to develop games in JS, How Phaser! along with the new Visual Scripting, simplified the game design (the foundation of the project), type Construct 2 or GDevelop (Open Source). Mono does not include C # simplifies Godot Engine! GDScript is fantastic! Python has improved! easy, with little code do it all! I do not see the sense of including C #. I hope you will include because Javascript. JS and HTML5 for 2D games is wonderful, and Godot Engine must be easy to use even for young designers who are not programmers! Then when you need it you write code! so Godot approaches all users, and become open to everyone! This should be Godot Engine!
You did a great job! Thank you guys! please, unprocessed Godot in Unity: D Unity is ugly!
SpaghettiDeveloper | 2016-08-17 00:12
Regarding “real-time games” and managed languages, there is the issue of Garbage Collection.
In UNITY there is a need for “a bag of tricks” to avoid trigging garbage collection during the games.
tebz | 2016-10-18 11:02
|
Reply From: | Hinsbart |
The current scripting language, GDScript, is implemented as a module. You can compile the engine without it, and C# support should be the same in that regard.
So, if C# will happen, you will be able to use a binary that doesn’t support it, if you prefer so.