Useage of rust in the source code

[the-ssd]

Is it possible for rust code to get accepted?

And if yes, what are the requirements?

For example:

1. Must be optional
2. Can only exist in modules/
3. Must support WASM

But why rust?

Ecosystem

There is a lot of code written in rust, that is also easy to add into your project.

For example, with serde you can easily serialize and deserialize
sha2 can be used to generate SHA-256 hash
rayon can be used to easily and safely parallelize code

see awesome rust for other examples

High Level

While having a low level language is great for performance.
A High level language is better for readability, and easy of use.
(Note that in most cases, we don't sacrifice any performance with rust)

For example, with enums (or unions in c++) you can do:

enum Number {
    Int(i32),
    Float(f32)
}

let num = Number::Int(5)

match num {
    Number::Int(i) => { /* use i */ }
    Number::Float(f) => { /* use f */ }
}

I am not c++ expert, so I don't know if there is a clean way to do this in c++ with variants.

Another example is unpacking Option<T>

let maybe_data = Some("data");

let Some(data) = maybe_data else {
    panic!("expected data");
};

// use data

This can be done in c++, but I am not sure if it will be as clean as rust.

Personal preference

Some people (like me) prefer to write in rust, and are more efficient in it.
It would be nice if we can write in a language that we prefer.
But it would also be nice if you reviewed in language that you prefer.

How to review code?

To be honest, I can only think of 2 solutions.

1. Learn rust basics and ask if you don't understand something
2. Have someone else do it.

Both of which aren't a good solution, if you don't want to learn rust
if you want to, there is rustlings which is a good starting point

How to integrate rust into c++ project?

CXX can be used for this.

[Calinou]

This was previously discussed in #1330 and was rejected, mainly due to concerns about buildsystem complexity. This would negatively impact the ability for new contributors to set up a toolchain and get productive quickly.

[the-ssd]

I can try to make an example module, this way complexity can be assessed.
And instead of failing to compile, print a warning like Rust isn't installed, module X won't be compiled. (see [link to docs])

[the-ssd]

I have made a VERY simple example. My goal was to make something working ASAP.
There are some things that are missing like setting correct target.

repo
diff

Note: Cargo.lock is generated automatically and shouldn't be changed by users directly.

Edit: made another commit fixing some issues.

Here is a list of improvements to make it better:

1. Use correct target
2. Ask to install rust?
3. The way it's done in the repo, dependencies won't be reused, which will slow down compilation if multiple modules use rust.

[the-ssd]

Also, in #1330 it seems like a lot of people this it is about rewriting Godot in rust.
Proposed used of rust is only in modules/ to keep build system simple, and optional to not interfere with c++ users.

[AThousandShips]

Mixing languages is a recipe for hard to maintain code IMO, especially having niche parts of the engine become dependent on very few maintainers

We already have too many languages IMO, with:

• C++
• C#
• Objective-C
• Kotlin
• Java
• JavaScript

However beyond C# all of these are platform specific and necessary (or area specific, like js for network code in websocket and webxr), and the C# is language specific, it's not used outside of that, adding another without it being necessary feels like just making things more complicated and hard to maintain, especially when it's for something that is unrelated to a specific language, like a module that isn't about a language

Remember: It's not just important that the code be easy to write now but that we can maintain it in a year, or five years, or ten years, when the original contributor might no longer be available, and it must also be relatively easy to maintain it

If you're knowledgeable in, for example, the way macOS works, you will also be able to use objective-c because that's what the OS API is written in, but with specific engine areas that aren't specific like that you aren't guaranteed to also know a specific language, so now you have skills that you could use to help with, for example multiplayer code, but you have to learn rust or some other language just to be able to apply that knowledge to help, that creates a barrier of entry

[the-ssd]

I agree that not having rust maintainers is a big problem. A possible solution is to ask other contributors to review and give advise, but it's not a good solution. Another solution is to find someone who will review everything in rust.

Or rust code can be considered third party.

I restart this discussion because I am working on a type system for GDScript. And in my case c++ isn't an option.

Is there anything that can be done to make it possible to use rust in the engine? Or will this never happen.

[AThousandShips]

I'm not saying it's impossible or won't be done, I'm just giving some of my reasoning and some arguments (IMO strong ones) why this isn't a good idea and would make things much harder to work with, we really don't need to make the general review process harder, it's taxing enough as it is

My main issue here is that I don't see any really good or strong reasons for why this should be allowed, other than convenience over learning c++, that's what's really lacking in my opinion, without even that I fail to see the reason to make things harder to maintain and work with

Take, for example, the macOS case, I don't know objective-C, and I don't like it very much as a language, but AFAIK if we want to be able to work with the API for macOS we have to use it, we can't get around it, at least not without an unreasonable amount of extra work or flimsy libraries

For the third party part we really also don't want to add stuff that's "half maintained" or "on best effort" without good reason, if we absolutely need to that's one thing, or have to accept that parts of the engine just aren't maintainable any longer, but starting out in that position feels backwards

[the-ssd]

Aside from convenience rust ecosystem is pretty good. And reviewing rust is sometimes easier because it's a higher level language.

It won't make it harder for c++ maintainers, since they won't be reviewing it. And since rust will be optional it should affect c++ devs if some it gets deprecated.

[AThousandShips]

I think I've already answered your points and why that's an issue above, so I'll disengage here (to clarify, my bad, that I mean I won't go in circles), but those are just my arguments, and other maintainers and reviewers might disagree

For the c++ maintainer part maybe I wasn't clear enough, so I'll add a final point there:
Maintainers have their specific areas of knowledge, like network, graphics, physics, etc., and their expertise is required for approval in their area, that's the issue with language, they now would have to know rust as well, especially if it's a niche area

[Zireael07]

To add, Godot already has trouble finding maintainers for some areas @AThousandShips mentioned. If Godot starts requiring they know Rust in addition to C++, that will make it even harder,

And "best effort" and "optional" words being thrown around do not make me trust you know exactly what is involved in what you are proposing.

[Bromeon]

I'm sorry to say this, but as someone who uses Rust on a daily basis, I find it hard to take the proposal seriously in its current form. For a change of this scale, you need to provide a much better informed analysis than "has some nice features/libraries" and "some people prefer Rust". There is a large number of considerations you simply ignore:

• The current know-how and skill of the team is heavily surrounding C++.
• It is unclear if you find (skilled, non-zealot) Rust developers and contributors as easily as C++ ones.
• You make no mention of Rust imposing a very strict ownership/borrow model and if that would be appropriate for Godot.
• A lot of the engine development is limited by hard, domain-specific problems (rendering, platform support, etc). that have little to do with the programming language.
• There is no plan how to represent the node hiearchy in a language that doesn't support inheritance.
• You mention libraries like serde, cxx, but have you used them on a larger scale? While nice, they are very proc-macro heavy and can considerably impact compile times, to the point that some people recommend outsourcing serde models in a separate crate.
• Your point "Ecosystem" ignores that C++ has been around 20+ years longer than Rust, and that you can simply benefit from the entire C ecosystem for free.
• "How to review code" - "Have someone else do it" -- you are joking, right? 😬
• You didn't even begin to consider any sort of migration plan or strategy.

I'm not writing this so that you can convince people to switch to Rust (you won't), and I'm also not saying there is no merit in the idea whatsoever. But as an advice for suggesting changes in the future, also outside Godot: this needs proper research. The larger a change, the higher the burden of proof lies on you to make sure there's merit. In particular, it's not the task of the other side to argue "why not" as long as you don't present significant reasons on "why". Hope that helps 🙂

[Zireael07]

To add:

1. compile times suck in Rust the moment your project is more than a toy and serde does make that worse
2. Rust GDExtension team had to do magic dances around the borrow checker for things that are trivial in C++

[lilizoey]

i do agree that this is a bad idea, but dont entirely agree with those two points:

To add:

1. compile times suck in Rust the moment your project is more than a toy and serde _does_ make that worse

This is a bit exaggerated, godot takes a long time to compile (at least on my machine) currently and i dont think a hypothetical godot made in rust would really be significantly worse.

2. Rust GDExtension team had to do magic dances around the borrow checker for things that are trivial in C++

bromeon and i are the maintainers of that actually. but really the issue is just that some c++ idioms dont translate well to rust (and the other way around sometimes). in theory the godot devs could cater more to rust which would significantly help, but it would also be a lot of effort on their part for marginal gain so it's not really something to expect. if in theory the godot devs introduced rust in godot they would likely cater more to rust which would fix a lot of the issues like that.

none of this to say that i think the godot devs should use rust in godot, but i dont think these two points are very good reasons.

[the-ssd]

TL;DR No good reason why it should be allowed

[bend-n]

I really dont think thats the TL;DR, i think you instead said:
"Too Long, i must be completely correct because i am always correct about everything and i am never wrong".

[lilizoey]

there's no need to be snarky

[the-ssd]

I really dont think thats the TL;DR, i think you instead said: "Too Long, i must be completely correct because i am always correct about everything and i am never wrong".

If you want the long answer, then here it is:
I asked this to see what are the requirement for rust to be accepted, and I got the response - maintainers.
I expected that it's unlikely for rust code to be accepted. And still think that maintainers aren't the only problem.
(If you think I am lying, then see How to review code? Where I admit that there isn't a good solution.)

Aside from that, the reasons to use rust in Godot aren't that good.
(Ecosystem - C++ also has one, Preference - maintainers also have one, High level - not important)

[Pspritechologist]

I really dont think thats the TL;DR, i think you instead said: "Too Long, i must be completely correct because i am always correct about everything and i am never wrong".

I think you may have misread their comment?