Gluon

[ShalokShalom]

Gluon is an embeddable scripting language, very much what Lua is to Cpp, just for Rust. It is very similar to the ML-derived languages and has interesting properties, like calling Rust functions and so on..

I think thats a great scripting option for Bevy
Github

[memoryruins]

See #142 for external scripting initiatives. Built-in scripting appears to be a non-goal for bevy #114 (comment) . Gluon is certainly nice though ^^

[aclysma]

There were some really good thoughts in this comment on another issue from @cart regarding a development process for "big new features": #179 (comment)

[ShalokShalom]

I can see your concern and I read the linked articles.

Here my thoughts: Gluon does violate none of the mentioned issues that cart has with the scripting approach;

It mearly solves it, since people will otherwise split the investments into Bevy and its forcasted forks:

My default answer is that scripting is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.

Gluon is not breaking the ecosystem in this way.
It is expanding it.

[minecrawler]

@ShalokShalom from @cart 's post in the Amethyst community:

Exhibit A:

I dont intend to stop people from making 3rd party scripting plugins or extending Bevy to make that possible, but I currently have no intention of endorsing those plugins officially. And I won’t compromise Bevy’s rust APIs or overall maintainability for scripting.

Which means that you should create a Gluon plugin by any means, but it won't land in the Bevy repository (soon) unless you find very strong reasons or @cart changes their mind. In my mind it will probably play out in a way that someone creates a third-party plugin and at some point most Bevy users use that one and nothing else, at which point it might become official. So you should push Gluon to become that one plugin everyone uses.

Exhibit B:

I think adding official support for multiple [scripting] languages to an engine is a mistake.

There will probably only be one language, so you should compare Gluon to other viable options and explain why Gluon is so much better than them in a non-emotional way. Keep in mind that while Gluon is a great language, there are other candidates, too, and finding the most optimal one and ultimately making the decision to offer it officially is a very hard and probably also emotional choice.

[ShalokShalom]

Objectively, Gluon is more an abstraction layer on top of Rust, less an own language. That is the property which I think could serve us as orientation. Subjectively, I love the meta language heritages that it shares with OCaml, Haskell and Rust, including all its benefits and the simple syntax.

Personally, I think that are good properties for a scripting language on top of a stable framework of an engine, that has shown the intention, to provide pragmatic and concise solutions.

[StarArawn]

I would be more interested in allow users to more easily create plugins for scripting. Not everyone likes or wants to use gluon. I want to try and add a scripting plugin for wren. There is an issue open here about working towards that goal:
#142

[ohmree]

Gluon is an embeddable scripting language, very much what Lua is to Cpp,

Wouldn't you say Rhai fits that description better?

While it has some quirks like closures being implemented as anonymous curried functions, it is more Lua-like than Gluon in at least one major way - it's dynamic (if that's a plus or a minus is up for debate, I assume).

Its syntax is also simpler and rustier in my opinion.
For example: in the example on the Gluon website you have things like the do keyword and the ? symbol that aren't very obvious for someone coming from Rust, while Rhai's syntax (in my opinion) is easier to grasp for a first-timer coming from Rust.

[erlend-sh]

If we get into language comparisons I'm afraid we'll steer this issue way out of course (fun as it may be!).

The issue seems resolved to me, as per @minecrawler's response:

you should create a Gluon plugin by any means, but it won't land in the Bevy repository (soon) unless you find very strong reasons or Carter changes their mind. In my mind it will probably play out in a way that someone creates a third-party plugin and at some point most Bevy users use that one and nothing else, at which point it might become official.

[ShalokShalom]

I am fine with multiple attempts and also with a global platform for those. While the goal of this issue to discover the usability of Gluon for this purpose and not the personal preference of some individuals.

[erlend-sh]

the goal of this issue to discover the usability of Gluon for this purpose

And the resolution is that there’s nothing we can discuss here that will do a better job of usability-discovery than an actual Proof of Concept in code ☺️