Support for more programming languages other than python?

[rubyFeedback]

I filed this under Question because this seems to cover most of it, but it is also a suggestion,
so ... not solely a question only.

I looked on the homepage and python code is shown:

from azul import *

css = """
    .__azul-native-label { font-size: 50px; }
"""

From this I infer that python code works for azul too, and even (!)
CSS. Which is great.

I am looking for alternatives to gtk but also libui (which, at the least,
works on windows out of the box in ruby) - but I am looking to want
to use ruby. gtk has one advantage in this regard in that it offers
bindings via gobject-introspection.

How difficult would this be to add for ruby, and what would be necessary?

I assume it is a "finite" problem set as python already works on azul (I
assume so from the example). Could someone perhaps add a short
document explaining what would be necessary for adding more language
bindings? This is one area where libui excelled - tons of people created
bindings in the respective language.

Unfortunately my C/C++/Rust knowledge is very limited. I am quite ok-ish
with ruby, I can even use python too just fine, but preferably I would want
to use ruby since I wrote so much code in the last ~20 years in this
regard already. All my commandline stuff for instance. Right now I use
either the www or ruby-gtk3 for add-on GUIs to the commandline
code.

[rubyFeedback]

So this is also a bit a request for documentation. A separate file
would be nice, linked in from the main README. It's also ok
if this is outdated. Better to have outdated documentation than
no documentation.

[fschutt]

The "build.py" approach was migrated into the azul-doc crate and language extensions for 20+ languages were generated in https://github.com/fschutt/azul/tree/master/doc/src/codegen/experimental

They are not hooked up with the main azul-doc build tool (now written in Rust instead of Python) however. If someone has spare time, you could look at how the Python code is generated and then add support for your favourite language.

The reason I added Python was to check that it is technically possible to bind it to a VM-based language. For VM languages (not direct C API), you have to do some special tricks to get the function pointers to work.