Specify capabilities and limitations for each language (aka Yelp for Godot Bindings)

[Xananax]

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

[Vivraan]

Didn't particularly get this one: all languages in this list maintain C interoperability so whatever external library can't be linked won't work, right?

I don't immediately see how a specific language will limit a programmer in accessing Godot bindings, and if it's a limitation of the language it's not within the scope of our document - we only provide our best estimate of the quality of Godot bindings available for a specific language!

[Xananax]

That's possibly a bad example then, and maybe I shouldn't have mentioned it, but I meant, more generally, to list any limitations that might bite the adopted of a language in the butt later down the line

[ShalokShalom]

To be clear: Language or implementation limits?

[Vivraan]

To be clear: Language or implementation limits?

+1

[ShalokShalom]

That is a question? 😂

[ShalokShalom]

Limitation in HTML exports:

1. Language (runtime) needs to be ported to wasm.
2. This patch/progress need to be done for GDNative languages: https://godotengine.org/article/godot-web-progress-report-2

godotengine/godot-proposals#147

[Xananax]

Language or implementation limits.

Here's the use case:

• I am interested in Godot-Ecmascript
• I decide to use it
• Turns out, HTML exports don't work. I didn't know, because I didn't think to check

Other user case:

• I am interested in Godot-Lua
• I realize half way in my project Godot-Lua doesn't have any support for export hints, I can't properly expose my variables to the editor

I don't know if HTML exports don't work with Godot-ecmascript, nor if Godot-Lua doesn't support exports; those are hypotheticals. I've tried running a simple game with Godot-Ecma and it didn't work, but I don't know if it's for lack of support or because I missed something.

My point is simply that for a supported language to "work", there is a certain level of expectations from a user's perspective. Are those expectations met?

Some examples of expectations I can think of:

• Exports for all Godot-supported platforms (Windows, Mac, Linux, Android, IOS, HTML, Server)
• Full editor support
• Full Godot API support
• Support for threads (in all supported platforms?)

[Vivraan]

Language or implementation limits.

Here's the use case:

• I am interested in Godot-Ecmascript
• I decide to use it
• Turns out, HTML exports don't work. I didn't know, because I didn't think to check

Other user case:

• I am interested in Godot-Lua
• I realize half way in my project Godot-Lua doesn't have any support for export hints, I can't properly expose my variables to the editor

I don't know if HTML exports don't work with Godot-ecmascript, nor if Godot-Lua doesn't support exports; those are hypotheticals. I've tried running a simple game with Godot-Ecma and it didn't work, but I don't know if it's for lack of support or because I missed something.

My point is simply that for a supported language to "work", there is a certain level of expectations from a user's perspective. Are those expectations met?

Some examples of expectations I can think of:

• Exports for all Godot-supported platforms (Windows, Mac, Linux, Android, IOS, HTML, Server)
• Full editor support
• Full Godot API support
• Support for threads (in all supported platforms?)

What I read from this was provisional QA testing of bindings!

A noble act, I admit, where we test the language bindings and provide our own rating for them!

It is much more foolproof compared to simply pasting existing info from their READMEs.

If you find the time, please look into each of these bindings and provide your analysis! Also, it might help us if you can provide a checklist which noobs like me can use for testing language bindings! 😁

[ShalokShalom]

I think we can automate a bit at least. Isn't there the chance to check the API compatibility in some automated way?
We would also contact the maintainers, in order to evaluate this.

[Vivraan]

Absolutely, we can write unit tests which correspond to items in a checklist expanded from @Xananax's list for all the languages!

Consider that "full editor support" means that a number of different editor features need to be accessible via the bindings, each of which is an item. Likewise for Godot API support (Editor support ⋲ API support iinw) and multithreading support and whatnot.

[ShalokShalom]

@perbone Is Lua capable of exporting to HTML?

[perbone]

At the moment no. It's on my list of next things to do.

[ShalokShalom]

Some more HTML5 stuff: C# is supported, despite not being listed in the documentations as such (got already reported)
And C++ modules are obviously also supported. GDNative generally not, so that leaves us with GDScript, C# and C++ modules for now? I suggest to list the other .Net languages all in one category, to describe them.
Like Clojure, F# and so on:

___________|__________|______________________
F#, Clojure    Mono     All Platforms, via C#
C#             Mono     All Platforms
C++ module   Native     All Platforms

And so on

[Vivraan]

HTML5 support is limited to the non-GDNative stuff. That's already one less reason to use other languages tbh, since I'm assuming that there's no WASM/JS support through NativeScript yet.

[sheepandshepherd]

Supposedly GDNative will work on HTML5 soon according to this news post from last month:

stay tuned for more as GDNative support is coming to web and that's a matter for the next blog post.

But I haven't seen any details or announcements about this. No idea who's working on it.

[Vivraan]

Wish I could tag @Calinou here.

[ShalokShalom]

I mentioned this already: #13 (comment)

[Calinou]

GDNative support in HTML5 is still coming, but I don't know for sure if it will be available in 3.2.4.

[ShalokShalom]

See here the tracking issue:
godotengine/godot#12243

[Vivraan]

@ShalokShalom I guess we can now open a PR to address #7, #11, this (#13), and #20.