C Bindings wrapper for ReX?

Just testing the waters here, this is just to see what the community thinks.

Recent events in the world of Linux kernel development has brought this question to the forefront. And we have been thinking about it ourselves too. (largely myself)
The question at hand, is should we work towards a future where we have C Bindings for the core engine, enabling contributes to write engine code in other C ABI compatible languages (which C++ isn't) its becoming more and more of a reality that new developers are wanting to use newer more modern languages.

We have asked the question, would it improve developer morale and interest if they could contribute in other languages? I would expect the answer to be yes, but it would come with a lot of things that have to be very carefully thought out and considered.

Some of the highlights we considered right away were:

• Maintainers per language
• A Maintainer for the C Wrapper itself

This is NOT to be taken as any level of promise or road map feature, I just simply want to find out what the community thinks are the pros and cons of trying to support such an endeavor, ReX as one of its core tenets is to look to the future, and slowly but surly developers are moving to other languages.

Those of you that have the knowledge on this kind of thing, feel free to chime in on what kind of implications this would have, from management to performance. And more importantly to the developers out there, Would you be more excited and willing to contribute if this were a reality?

Zeftax On improving developer interest: I would be interested in contributing from time to time, what are some issues I could get started on? My experience is mainly in autocad extension development, not sure if its relevant to anything you're doing

Well to this point, IIRC autocad extensions were done in C#, where Redot is done in C++ we'd love to explore options if you had C++ experience or wanted to learn it.

But this perfectly underscores the issue at hand doesn't it? C++ isn't the most loved language (subjective), finding contributors that both have C++ skill, and also time to contribute is not as high as you might think. So, that was a lot of the angle of my OP, can we increase that talent pool and interest for the future if we move to make things a little more flexible?

Bottom line is the end result right, even if it did make it more complicated to maintain, would it result in a better product or user experience in the end?

Zeftax Well, i guess the next question would be do you want to contribute to the stable release or ReX what this topic was made about? Actually.. we have in the past refereed to ReX as experimental, but we are going to be pivoting that branding soon, We don't want the release to be thought of as unstable or experimental, as we will curate stable release tags for it.

That said ReX is where most of the feature development and progress will happen, at present 3 features are already in the works. But with that comes the philosophy that we aren't as worried about deviating from Godot over time, if we are to look to the future we must not focus on the past.

The main release (Simply called "Redot") will be much less likely to deviate from Godot and much less likely to break the core API over time, but with that will also be much less likely to add new/major features. With that, contributing to the main release "Redot" will be much more strict and much slower on what can be changed or added.

Ultimately its up to you i suppose, the two teams are led by different people with different styles and ideals.

And lastly, team communication is going to be another point, as we primary use Discord to communicate and coordinate, i'm not sure if you have equal dislike for discord, as you do GitHub, but since i haven't seen you there i assume so.

Zeftax And it's not that we entirely disagree either, its just simply that you can't move a community this large easily.. we don't have the market share that Godot does, its true we put a dent in it, but they can pivot and most of the community would follow. With us that isn't really the case. the initial hype is over that brought in most of the community, what we gain now is only by word of mouth and some YouTube marketing.

As much as we understand your position, it just isn't practical to run a community outside of the industry standard services that everyone already uses, doing so would be a death sentence.. We recently tried to solve this by bridging Discord with Matrix, but discovered that we can't do that as it is disallowed by the Discord TOS and since the entire community is on discord. we can't risk a violation there.