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.

I thought its a good idea to have one issue for each language. To start with Ecmascript is a module language and should have editor support: pragmagic/godot-nim#66 (comment)

Announcement 🥳

Hi, lovely people.
Godot is more than a game engine.

It is also a suitable tool, to develop completely normal apps, and even sophisticated web pages.

It can be used to develop all kinds of software and due to its small size and the node based workflow, is it more suited in those cases than Unreal, Unity and other tools.

What is hindering though, is the lack of supported languages out of the box.

This community repo here does a significant contribution by adding a good overview about the landscape of supported languages.

What comes next?

A dedicated version of Godot, providing out of the box support for those languages, who are production ready.

I like to be part of that project, and also integrate a proper editor, probably in the form of an embedded terminal with Helix running in, that can also be configured via the Godot UI.

Make a full IDE out of Godot.

### (TODO)
(Per-module support feature legend. Currently, Rust (IIRC) doesn't support the video encoding module.)

This section should be removed and discussions on this should occur in this thread.

This was recently released. It adds Clojure support:

https://github.com/arcadia-unity/ArcadiaGodot | http://selfsamegames.com/pages/posts/arcadia-godot.html

Crystal is a language similar to Ruby, but it compiles to native code. There seems to be some attempt to bring it to Godot: https://github.com/kalinon/godot-crystal
The binding looks as dead as Ruby's though.

The reason for this proposition is:

1. There can be more than one implementation of a language binding, in which case separating them by rank may not be convenient for reading.

2. The new list can be sorted more conventionally as:

   {Language} {category-emoji}*

   1. {Implementation [0-9]+}

      {Description}

3. This is more easily maintainable as ranks can be added just like any other category emoji.

See my comment in godotengine/godot-visual-script#38.

Compare reduz response:

Unlike Unreal, this is more meant as a complement to programmers, so game designers, level designers, etc. can work more easily.

I'm not quite sure about this statement, but I kind of doubt for this opinion to be outdated even in 2020.

The thing is that 99% of people do think VisualScript is indended for non-programmers in spite of this. So I'd just combine the two statements perhaps, because by now the community's effort is to make it easy-to-use even for non-programmers?

There are certainly engines which target "no coding required" philosophy, better than Godot IMO, of course they're more limited in comparison.

i18n

Let's welcome translation efforts for our document!

Any and all translation effort is welcome, although I believe the following should receive priority first:

1. French
2. Spanish
3. Russian
4. Simplified Chinese
5. German

I myself can translate Hindi and Indian Bengali, although they don't strictly need immediate translation since most Indians using Godot understand English.

However, if you're skilled in a particular language you are free to provide a humanised translation in it!

l11n

I guess we should stick to American English spelling for now.

https://monnef.gitlab.io/golden-gadget/

Which language limits which exports, and in what manner?

Possibly also: which language limits consuming external libraries, or other potential limitations that somebody picking a language should be aware of

Related: #7

Since Godot 4 offers a completely revamped API for language bindings, all already developed bindings are completely useless.

I introduce a tag "Godot 4" and announce this thread as a visible reminder and eventually as a coordination platform to integrate the new bindings.

So, do we create a new section at the top of the current README for the new bindings, once they come in?

Or a completely new repository?

Also guides, blog articles and similar stuff to help with the development might help.

Thanks for contributing.

I have added support for the Swift language in the godot-swift repository. The framework isn’t mature yet, but it already has a pretty comprehensive feature set, and a reasonable amount of documentation (which I am actively expanding right now.)

Consider adding to the “Has Potential” section?

https://github.com/geekrelief/gdnim

This was recently released. It adds Clojure support:

https://github.com/arcadia-unity/ArcadiaGodot | http://selfsamegames.com/pages/posts/arcadia-godot.html

Github is a proprietary platform, so I considered replacing it. While I see an alternative, which might work more effectively:

We could also use Github to contribute and link our mirrored instance, to expose the viewers to an alternative and make at least a little bit good karma this way. 😉

This keeps the project easier to contribute to, since most people do use Github.

3 different open source alternatives to Github were tested:
, Phabricator, Gitea and Gitlab.

Phabricator, hosted at the community maintained gitpull.it
coming soon

Gitlab it extremely slow, the import was a pain. https://gitlab.com/ShalokShalom/godot-lang-support

Gitea seems to be the closest to Github, very fast:
https://gitea.com/ShalomShalom/godot-lang-support

My favorites:

1. Gitea
2. Phabricator
3. Gitlab

What do you think of it?

Much fun 🥳

I have written bindings for the Zig language, which are more developed than the one listed here and actually usable.

The Python plugin manager mentions debugging support in Pycharm, I asked him to specify that, so to give us a good overview of the supported editors and the supported platforms as well.

This serves as the main Python issue, and stays open, as all the other language specific issues.

Much thanks 🥳

Current doc lists an old repository with Go bindings, seemingly being abandoned (https://github.com/ShadowApex/godot-go).

User surgical#3758 on Discord just announced a new project of theirs, claiming it to be ready for "alpha use": https://github.com/godot-go/godot-go/

We should probably mention it in the list, but that raises a question of how to show contesting libraries in the best way as to not confuse readers? Here we can probably remove Go from L4D section or mark it as being replaced by something else. But there can be cases where different groups are working on the same language support, as was with Kotlin until recently.

https://github.com/dsrw/enu

Pretty wild, what should we do with this one?

Let us collect Framework support?

https://github.com/alfredbaudisch/GodotPhoenixChannels

About time we did this, this hadn't crossed my mind.

could you help to identify the origin of this emoji, that you put in? @Vivraan

mozilla-mobile/fenix#20407

Apparently there's a new GodotGo repository that, like F#, "surfs" on the C# bindings by transpiling the Go code to C#. Should probably be added to the list.

Where do we put this?

https://github.com/eutro/gdlisp

Tag a friend willing to collab on this resource!

Is currently functional, looking for devs to have a play with to discover issues.
https://github.com/grow-graphics/gd

I suggest to link issues, who are relevent to the support.
Like: touilleMan/godot-python#146

There's new haxe language support https://github.com/HaxeGodot/godot

Anything else?

@ShalokShalom think it will help if we make one.

I've already started the process, could you look into it?