Use of Rust inside DDNet client/server

[heinrich5991]

While implementing past pull requests like #5064 I've been thinking about implementing them using Rust instead of C++.

Rust is a language targeting a similar audience as C++. It tries to completely rule out any memory unsafety and thread unsafety. I've used the language in the past for university assignments, hobby projects, projects related to DDNet such as https://github.com/heinrich5991/libtw2 and most recently also the DDNet HTTP masterserver (src/mastersrv), and I think it'd be nice to also be able to use it inside DDNet.

If this is wanted, I'd propose to start by implementing a small, optional feature in Rust first. This way, it could be easily ripped out again if we encounter any problems.

For interaction with our existing code base, I'm eyeing https://github.com/dtolnay/cxx/ which is also what Chromium was considering IIRC.

Pros

• Allows to write code in an environment without segfaults and thread safety problems.
• Has some higher-level primitives than C++.

Cons

• More languages in the code base lead to more complexity when coding, building (also cross-compiling) and debugging.
• Existing contributors might not be familiar with Rust, leading to code that cannot be maintained by everyone.

Other

• Rust targets fewer architectures than C++, but I think this is not a problem for DDNet, as all platforms generally targeted by DDNet are well-supported by Rust.

Unresolved questions

Which version of Rust do we want to target? Probably one shipped by some old Debian? …

What does everyone think about this?

[Chairn]

Well, i've never written any rust, but it could be a start for me.

• Which part of DDNet would you like to see rewritten in Rust ?
• How big is the dependency for all OS : 1. for compiling ? 2. for runtime ?
• Our codebase, especially the game physic sometime rely on UB. I believe Rust does not have the same UB (or no UB at all?)

[edg-l]

I'm in favour of this but i'm obviously biased :).

About some code not being able to be maintained by everyone, i think its not a problem since this already happens, we already got a "graphics" guy, a pred code guys, etc...

[heinrich5991]

• Which part of DDNet would you like to see rewritten in Rust ?

I don't want rewriting in Rust to be a goal of this. It's more of a "if a components gets rewritten anyway or if a new component gets added, allow to choose Rust as the language".

• How big is the dependency for all OS : 1. for compiling ? 2. for runtime ?

Good question. I don't feel like the compile time dependency is that important, but the runtime one is definitely interesting.

• Our codebase, especially the game physic sometime rely on UB. I believe Rust does not have the same UB (or no UB at all?)

I would not dare touch the game physics with something like a rewrite, especially in a different programming language.

[heinrich5991]

Ah, another problem:

Building will get more complicated on Windows, new contributors would also need to install Rust by downloading https://win.rustup.rs/x86_64 and executing it.

[C0D3D3V]

I would not like it if we split the codebase of the client and server into multiple languages (It is enough that we use python for some strange performance reasons, to build the net-object parsers). I don't see a big advantage in using Rust for individual components. Furthermore, I find Rust not a very simple language in terms of syntax. I have only written a few small tools with libtw2, and found the syntax and concepts horrible. C++20 should contain enough concepts to polish up the code. We don't need to complicate it unnecessarily by using Rust. I don't mind other tools that we ship being written in Rust (like the masterserver) but otherwise I don't see any advantage to it. Except that the devs are motivated to learn a new language. However, I don't think I'll ever be friends with Rust xD

[Jupeyy]

I'm generally for it,

there are a few criteria I'd say that must fit tho:

• We need at least 3-4 relatively active rust maintainers. If someone adds broken rust code and nobody can fix it for a few months that sucks
• Cross-compiling must be similarly easy as now
• We should still allow new code in C++ (even for new modules, whatever). We cannot really expect, that everyone shifting to rust really quick

Maybe there is more, but that's my start on it

[heinrich5991]

C++20 should contain enough concepts to polish up the code.

C++20 (or C++ in general) doesn't try to make segfaults, thread-unsafeties impossible.

[heinrich5991]

• We need at least 3-4 relatively active rust maintainers. If someone adds broken rust code and nobody can fix it for a few months that sucks

Sounds sensible that we need enough active maintainers that can do Rust.

• Cross-compiling must be similarly easy as now

Good point.

• We should still allow new code in C++ (even for new modules, whatever). We cannot really expect, that everyone shifting to rust really quick

Yes, definitely.

[sjrc6]

I don't contribute as much as others so you don't have to listen to me, but I feel like rust and c++ are designed to accomplish very similar tasks so it feels a bit redundant to include both. Also maybe consider how much complexity will be saved by using rust vs how much complexity is added by using two languages, I feel like it's best to take a conservative approach as well. Personally I don't mind having to learn rust though.

[ChillerDragon]

First the slow linker now longer compile times. Yikes. DDNet is one of the fastest compiling projects I know. And that is very nice for my try and error development flow. Please do not break that speed :(

But yea other than that. I am not a rust dev but I can see the advantages of rust. Also I do not think that simple rust code is excluding more devs than some of our complex C++ code.

[Jupeyy]

Can we make a benchmark before judging?

If the compile time goes up by 1-2 seconds, that's fine imho

[C0D3D3V]

I've been reading up a bit about Rust. And among other things read this: https://dev.to/daaitch/understanding-rust-as-a-c-developer-2o28

I wouldn't be against using Rust in our client/server code now.

[Learath2]

While I'm generally okay with this, I'm not a huge fan of FFI and the problems it brings. I'm a little scared of the friction at the boundary of C++ and Rust. It'd be really nice to see a bit of what you imagine the boundary might look like.

How you'd wrap our classes? How interactions would go, e.g will we be using a hook pattern through which C++ would call into Rust code?

[edg-l]

I've been reading up a bit about Rust. And among other things read this: https://dev.to/daaitch/understanding-rust-as-a-c-developer-2o28

I wouldn't be against using Rust in our client/server code now.

maybe this is better https://github.com/nrc/r4cppp

[heinrich5991]

The current "support" for Rust code should maybe get stripped out again, it's not doing anything useful and increases build times.

I'm currently half-working on #5411 (see #6961), but it might still be some while until it's done.

[ChillerDragon]

The current "support" for Rust code should maybe get stripped out again, it's not doing anything useful and increases build times.

I'm currently half-working on #5411 (see #6961), but it might still be some while until it's done.

Meh I already depend on the current rust code in downstream. Yes it is useless and yes it slows down compile time. But it has been doing that for a while. Why change that now? I thought it's to keep the codebase ready for when someone wants to use it.

[heinrich5991]

What do you use it for? I'm interested.

[ChillerDragon]

What do you use it for? I'm interested.

I use it as package manager. Having cargo and crates is nice. I installed some rust package that gets the string width supporting wide characters. So I can properly align the server browser in my curses client term-ux