I like Lua. I started using it in the Backend with OpenResty after discovering Defold.
1 Like
Yeah, I asked about code gen, since this makes F# and Clojure support impossible.
By implementing the API normally, it would have been compatible with all dotnet languages (for no extra work)
Since there is also Python and PHP supported, that would have been awesome.
Thanks for answering!
Not sure why that would be, as we generate wrappers that call our C/C++ api. If it works for C#, I donât see why it wouldnât work for more languages.
By implementing the API normally
Having the api written in C, and then let use our C++ and C# apis call that sounds pretty normal.
It certainly is compatible with C#.
Since there is also Python and PHP supported
What do you mean? Supported where?
I mean calling it via the same API. The whole point of .NET is to have a platform, that hosts different languages.
Nearly every single library and binding for C#, is also accessible for every other language on the platform.
As it is the case for JVM, both platforms use an intermediate language they compile to.
In case of the CLR, that is the CIL. Python, PHP, Clojure, F# and others happen to have compilers to this intermediate language.
Code gen bindings limit the accessibility to the language it has been done for, or makes it at least harder, depending on the implementation.
I think wasm for such an intermediate format seems more sensible, as said.
But having at least the dotnet languages with one binding, would have been nice too.
Anyway 
Our goal was never to include a .NET runtime in Defold but to specifically add support for C# as an additional extension language. We decided to do this via Native AOT compilation of C# code, not via JIT compilation of IL code.
The idea is also that the C# to Defold engine bindings should be generated from a C API. The Zig bindings should also be generated from the same C API.
3 Likes