Godot-proposals: Add support for multiple .NET languages to have "built-in"-like support. F#, Visual Basic, Etc.

[willnationsdev]

Describe the project you are working on:
Plugins and a mobile app that uses .NET.

Describe the problem or limitation you are having in your project:
Using non-C# .NET languages in Godot is cumbersome since you have to create C# scripts anyway and then have C# classes inherit a third-party class's features. This is what the Godot F# Tools plugin I wrote assists with. However, I would prefer it if it were easier to add support for arbitrary .NET languages that build on the features in the current CSharpScript implementation.

For example, maybe have a MonoScript that acts as another layer on top of Script and then have more specific CSharpScript, and potentially FSharpScript or TypeScript, implementations in submodules. This would allow other languages to take advantage of some of the GDMonoObject work that has already been done. Even if support for other languages had to be downloaded via the AssetLibrary, I'd still think it could work very well. Though, I must admit, I know very little about the ramifications of dynamically loading in additional languages, but it sounds a lot like what the NativeScript submodule already kinda does.

Describe how this feature / enhancement will help you overcome this problem or limitation:

People who want to use their preferred .NET language to create Godot games would be able to do so much more easily, without having to hack support in through C#.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

I would propose re-organizing the codebase to make CSharpScript files be in a dedicated submodule folder within the mono folder (at mono/csharpscript) and instead replace them with a set of MonoScript-like files. Then provide avenues for plugging in other arbitrary MonoScripts, operating similarly to PluginScript for the GDNative C bindings.

Inheritance hierarchy would look something like this:

- Script
    - MonoScript
        - CSharpScript (built-in)
        - FSharpScript (via addon), can reference .fs files, interops with same MonoScript API.
        - Etc. (via addon), can reference .xx files, interops with same MonoScript API.

Describe implementation detail for your proposal (in code), if possible:

This would involve refactoring a lot of the C# Mono code to remove direct dependencies of C# code and syntax.

Projects would need to be generated and managed from the dotnet cli, more than likely, rather than manually creating the files in Godot's Mono-related C++ code. It would make it easier to operate with an arbitrary language.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

Involves direct changes to the mono module. Unrelated to scriptable changes.

Is there a reason why this should be core and not an add-on in the asset library?:

Involves direct changes to the mono module. Unrelated to scriptable changes.

[zetashift]

Does TypeScript support the .NET CLR as a target?
Anyhow I'm all for this as I have a profound love for F# and using it as a scripting language; related issue here: https://github.com/godotengine/godot/issues/12337 where neikeq mentioned:

The plan is to rename CSharp* ScriptLanguage/Script/ScriptInstance implementations to Mono* and make them abstract classes. Language-specific implementations should derive from these (we would still only support C# officially).

However I'm not sure where the Godot team will find the time for refactoring as I think people really only care for C#.

[willnationsdev]

@zetashift Enabling people to use Godot with their preferred language has been a growing concern ever since 3.0 where GDNative and C# were first introduced. Until then it had just been GDScript and C++ (I don't even think 2.1 had VisualScript, but I could be wrong - never used it). The point being that now there are roughly a dozen+ languages that one could choose to use for Godot and the trend has been to continue making it possible for people to use the languages they want. The MonoScript concept (and #119 honestly) would go a long way towards that, so I think there is incentive there. But the real shame is that neikeq is the one who is most familiar with the C# codebase. Like, I think he does around 90% of the CSharpScript-related PRs. There aren't many people that can contribute and/or help with the refactor, so it's basically a bandwidth problem.

[zetashift]

@willnationsdev I wholeheartedly agree, neikeq is doing awesome work but does also almost all the Mono work alone.
A MonoScript concept would be great, but I fear that a big refactor of the C# code or GDNative code will be postponed or delegated to the community, because the current solutions are ""just enough"" and other stuff might take priority.

So might this refactor be better for the 4.0 release?

[willnationsdev]

Oh, for sure. There's no refactoring happening in 3.2 (already in feature freeze, just bug fixes). But I also kinda doubt it would even get done for 4.0. The priority right now is probably going to be getting exports working for mobile/web if possible. And only when there is no more work to be done on those fronts might things get refactored.

[willnationsdev]

@ShalokShalom

You would appear to be writing off this community as one that does not respect the power and versatility of functional, declarative languages (correct me if I'm wrong). And I do not believe this to be an accurate assessment.

Godot has more or less been spearheading the effort of being a highly cross-language API for building content. This is evidenced by its GDNative C API and its inclusion of not just a domain-specific text language, but also C# .NET and a domain-specific visual language. There are even C bindings available for Haskell as a scripting language. So, if anything, the history of this project is evidence that the people here care about making Godot as flexible as possible. I think there's something like a dozen languages you can already use.

And it's not that you can't use F# either. Lars Kokemohr wrote a guide to using F# in Godot and I built on top of that to create F# tools to make it easier to generate the script boilerplate for the language. This Issue is just about making it easier to use F# since it is a functional language that could conceivably get out-of-the-box support.

What's more, neikeq, the lead .NET developer for Godot, has already mentioned that he has plans to refactor things to enable other .NET languages (as this Issue describes), but he just hasn't done it yet. Which makes sense since the priority should be getting exports working on as many platforms as possible first. I mainly created this proposal only to document and track the community's desire for the feature.

[ShalokShalom]

This is more a byproduct of being cross compatible between imperative languages, rather than explicitly supporting declarative ones.

[ShalokShalom]

The fact behind this whole thing is that scientific evidence gets ignored, also in the code base of Godot itself.

Sadly is Godot one of the, if not _the_ most advanced open source game engine, since others do care just as little and Godot seems to do it the best among those.

I see and appreciate your and others' effort, while I dont see actual support for functional languages.

[Calinou]

@ShalokShalom @willnationsdev Please keep the discussion on-topic about the proposal :slightly_smiling_face:

[aaronfranke]

F#, TypeScript, Etc.

Note that if we ever migrate to .NET 5+ (aka .NET Core), the list of supported languages is more limited. AFAIK currently only 5 are supported: C#, F#, VB, PS Core, and raw IL.

[panesofglass]

Would it be possible to also have MonoScript support static classes and static members? @neikeq noted this in https://github.com/godotengine/godot/issues/12337, and I've noticed a lot of newer C# codebases and frameworks supporting this style.

[zetashift]

This proposal being open, does that mean it's accepted?

[Calinou]

@zetashift No, as we don't really have a formal proposal acceptance process.