C#

[realkotob]

It comes bundled with the engine, it's production ready for all platforms, and it's definitely more actively maintained than the VisualScript which was also placed in the "Full Support" section.

Rust, Nim, and Javascript do not come bundled with the engine and are not maintained by the godot github organization, whereas C# changes are taken in consideration for making bugfix releases. The languages can't be put in the same category.

[Vivraan]

It comes bundled with the engine, it's production ready for all platforms, and it's definitely more actively maintained than the VisualScript which was also placed in the "Full Support" section.

Not until the warning dialogue popup for C# when starting up the Godot Mono Editor ceases to exist. Apologies.

We cannot make opinionated assumptions about the feature set of a given language binding. You are of course free to refer to issues or PRs from relevant repositories which prove otherwise, in which case we can attach a note to the language binding entries, but I don't think we should change the ranking of a binding unless officially stated by the maintainers of said language bindings.

Rust, Nim, and Javascript do not come bundled with the engine and are not maintained by the godot github organization, whereas C# changes are taken in consideration for making bugfix releases. The languages can't be put in the same category.

They are necessarily distinguished by other categories, such as the Official and Community support emoji-icons. However, I do admit that it might be difficult to rank them by making common assumptions about their level of implementation efficacy. I guess this does call for discussion.

@ShalokShalom @perbone @pycbouh @rosshadden @sheepandshepherd your thoughts?

[willnationsdev]

@asheraryam

It comes bundled with the engine, it's production ready for all platforms, and it's definitely more actively maintained than the VisualScript which was also placed in the "Full Support" section.

While it is true that C# is usable for all platforms, it has not had a long period of testing on all platforms (it only just recently got web and iOS support, iirc). As such, it's still technically experimental until people have attempted to use the language on every possible platform and any related bugs for those platforms are sorted out. GDScript and VisualScript, in contrast, have been running on every supported platform for quite some time now.

I do agree though that the language support docs here would be more clear if they communicated the hierarchical focus of the development team, which is something like this, I think:

1. GDScript
2. C#
3. VisualScript
4. GDNative C++
5. Community maintained languages

Rust, Nim, and Javascript do not come bundled with the engine and are not maintained by the godot github organization, whereas C# changes are taken in consideration for making bugfix releases. The languages can't be put in the same category.

I do think it'd be a good idea to, in the case that C# is not grouped together with GDScript/VisualScript directly, at least create a "bundled with engine" emoji that can be attached to them, to more clearly indicate what people can expect with the language support in the engine. And Official vs Community doesn't necessarily account for it because GDNative C++ is officially maintained, but is not distributed directly with the engine, unlike the C API.

@Vivraan

However, I do admit that it might be difficult to rank them by making common assumptions about their level of implementation efficacy.

Well, rather than "common assumptions", we've generally been going off of the level of activity we directly see in the development team, at least, when it comes to the core languages (maybe that might be a good term for them?). But you are right that we can't easily make assumptions about community-maintained languages. That's why we have to communicate with the maintainers and/or directly see what their written code is doing to see how they've designed their language support.

[Vivraan]

Rust, Nim, and Javascript do not come bundled with the engine and are not maintained by the godot github organization, whereas C# changes are taken in consideration for making bugfix releases. The languages can't be put in the same category.

I do think it'd be a good idea to, in the case that C# is not grouped together with GDScript/VisualScript directly, at least create a "bundled with engine" emoji that can be attached to them, to more clearly indicate what people can expect with the language support in the engine. And Official vs Community doesn't necessarily account for it because GDNative C++ is officially maintained, but is not distributed directly with the engine, unlike the C API.

I agree, the current categories do not fully communicate this intent. Both Editor Support and Maintainer categories are disputed, and hence we should definitely introduce detailed descriptions for these in the "Categories" legend section to clearly communicate what we mean when we use the respective emoji.

btw @willnationsdev sorry for not including you in the list of people but I appreciate your thoughts. 👍🏽

[realkotob]

@Vivraan It's not an opinionated judgement. C# is an official language and receives "Full Support" as it's maintained by the core team and comes pre-packaged with the engine. Whether or not it's production-ready, experimental, or feature-complete is irrelevant.

I agree generally with what was said, but my point stands that it doesn't make sense for Visual Script to be a tier higher than C# and for C# to be placed with language bindings that are on a vastly lower level of readiness.

[YuriSizov]

Why doesn't it? C# was lacking in support and compatibility for the longest time and only recently was able to catch up. Visual scripting, however, is fully compatible with the GDScript API, but is lacking in more high level abstractions specific for its purpose.

[ShalokShalom]

It comes bundled with the engine, it's production ready for all platforms, and it's definitely more actively maintained than the VisualScript which was also placed in the "Full Support" section.

The question is if the language is production-ready and definitely not if they are more or less actively maintained.

If I start a language today and work daily on it, is it very actively maintained and not production-ready at all?

Not saying this is the case for C#, while this criteria is invalid.

C++ is official and not very well documented (for the GDNative part) and people have struggles using it.

Officially supported means officially supported, not production ready.

Rust, Nim, and Javascript do not come bundled with the engine and are not maintained by the Godot GitHub organization, whereas C# changes are taken into consideration for making bugfix releases. The languages can't be put in the same category.

I am 100% against this. Once again, because the question is how usable a language is and not how much it is used, how popular it is, and by whom they are maintained.

This list is bias-free and only determines the usability of a language and its ecosystem.

Despite that, and based on what I read daily in chat, is C# most likely production-ready and Nim/Rust coming close behind, mostly hindered by HTML5 export and a lack of example games.

Those who know the implementations, speak very highly of them and we don't need to discriminate them, because they are unpopular. Somebody invested a lot of work into their plugins and documented them extensively, so I think they deserve to be called production-ready, once 1-2 games show they are in practice.

[Vivraan]

@Vivraan It's not an opinionated judgement. C# is an official language and receives "Full Support" as it's maintained by the core team and comes pre-packaged with the engine. Whether or not it's production-ready, experimental, or feature-complete is irrelevant.

I guess the contention is because C# isn't supported through GDNative but through Mono Glue. This makes C# support different from that provided for other languages.

We must make a new category mentioning the type of binding used. The community-maintained language bindings and the C++ bindings use GDNative, while C# does not.

[ShalokShalom]

This is already solved by our planned spreadsheet, I guess: https://github.com/Vivraan/godot-lang-support/issues/13#issuecomment-694722348

@asheraryam Do you know a couple of successfully shipped C# projects? I know they exist, do you know them by name? I support the move of C# to production ready by then. Thanks a lot for your input.

[ShalokShalom]

[Vivraan]

This makes perfect sense. Any external language would need to provide bindings for its language server (if one exists).

Doing this for external editors is really simple, and is even available for GDScript to external editors (like the VSCode GDSCript Language Server plugin which relies on a running Godot Editor process to access its language server).