Rust for OpenMW?

[KnightoftheWind]

I was wondering what the devs thoughts were on the Rust programming language?. I hear it has a lot of advantages when compared to C, namely for bug fixing and stability. If work on OpenMW started right now, what would you have done differently?. Would you base the engine on Rust?, or would it offer little advantage?.

[psi29a]

Many of us love Rust; speaking for myself; I'm not as confident using Rust as I'm using C++.

As for adding it to OpenMW sounds like a solution looking for a problem while also limiting the amount of platforms OpenMW can run on.

[KnightoftheWind]

From what I hear Rust is compatible with all major operating systems, but I'm not too sure on the mobile front. There is a lot of enthusiasm going around for it, that's for sure, and there are even some AAA games that are being made using Rust. Most notably one by ex-DICE developers, called "The Finals". So it seems rather capable.

I suppose there is no way of knowing for sure, but I was just wondering what the devs behind OpenMW thought of the language and if it would have had any benefit for OpenMW whatsoever.

Edit: It seems the devs behind "The Finals" have their own github page, which includes numerous open source projects involving Rust. Maybe something there would be useful?. https://embark.dev/

[Chris]

I suppose there is no way of knowing for sure, but I was just wondering what the devs behind OpenMW thought of the language and if it would have had any benefit for OpenMW whatsoever.

The main problem I have with Rust is that it relies on a single provider. At best you may have some different backends (or frontends?), but it ultimately relies on LLVM to actually compile it. The same people behind the compiler were also the ones controlling the language, so even when alternatives become available (GCC is pretty close to having an independent Rust compiler, I hear), there's still the question of how open the language is going to be between implementations. I'd hate for Rust to take over only to become Chrome-ified (where Google can implement features in Chrome and push them into the standard at the same time, giving Chrome an unfair lead/advantage and leaving everyone else constantly behind playing catch-up; if LLVM can implement Rust features at the same time as getting them standardized, alternative compilers could never keep up).

There's also the question of how much it can help. Rust's claim to fame is largely it being "memory safe", which adds overhead and causes complications (fighting with Rust's borrow checker is apparently a common thing, as it becomes difficult to do some things that should be simple). That it can't interface with C++ libraries is also a significant issue, since both OSG and Bullet are C++ APIs. The original D version of OpenMW tried to add a C interface for Ogre3D's C++ API, so it could do D <-> C <-> C++, but that was quite a mess and I doubt Rust <-> C <-> C++ would be any nicer.

I'd be more interested in trying out "cppfront" (on GitHub) or something similar, which enforces C++ core guidelines and cuts down a lot on unsafe memory problems, while being completely C++ compatible and allowing to dropping back to writing normal C++ code alongside it if necessary. It's compatible with existing versions of MSVC, GCC, and Clang, only requiring C++20 (or newer) support.

[psi29a]

I'm also in the cppfront camp; as I'm not convinced that C++ can't evolve. It certainly has and continues to do so.

[Ace (SWE)]

Mozilla did develop some C++ bindgen for Rust as part of their Servo project, so that they could do direct Rust <-> C++ linking, but it was apparently very limited in what exactly it could map.

Rust is definitely far from a bad language though, and I could see OpenMW picking up Rust-based dependencies at some point, since we already have dependencies that use C APIs - and Rust does support that particular use-case rather well.

[AnyOldName3]

I think it's probably the most successful attempt at a C++ killer in history, at least if you discount things like Java and C# that don't try and take C++ on on its own turf and also are implemented in C++. If someone came from the future, told me OpenMW had been ported to another language, and asked me to guess which one, Rust would be my guess. That doesn't mean I think it's worth doing the work to do it now, and that's pretending that there wouldn't be a whole bunch of other work involved in porting, wrapping or totally replacing all our dependencies.

[BlueSkySystems]

I was wondering what the devs thoughts were on the Rust programming language?. I hear it has a lot of advantages when compared to C, namely for bug fixing and stability. If work on OpenMW started right now, what would you have done differently?. Would you base the engine on Rust?, or would it offer little advantage?.

I'm obviously not a dev here, but the main "killer feature" for Rust over C++ (OpenMW is not C-based, it uses C++) is the claim of "Memory safety">

Memories may be short, but the internet rarely forgets, as OpenMW started on a similar language called "D". D is a great language, but it was not mature enough at the time, IMHO, to really do OpenMW justice, and you also have an issue of accessibility. The further you deviate from C/C++/Python/PHP type languages, the fewer people can manage them. C and C++ dominate app development and have close to 40 years of history. PHP is the king of web dev, though very different from C/C++ contextually. Python is a good all-around scripting language, it has replaced Perl in some applications; competes with PHP for web dev; is used in scientific/academic spaces and such.

Rust is clearly far more successful than D, but I echo some of the other concerns here and have some of my own:

1. Rust is currently super-unportable compared to C++. It has far fewer compilers, far fewer architectures it supports upstream (e.g. you can't even get i586 to compile. Yes, i586 systems are obsolete but that's still a pretty common uarch of 32-bit x86!!!)

2. Rust's memory safety comes with performance drawbacks, a high learning curve for developers (leading to dev attrition), and still doesn't resolve issues of memory leaks, which for a game is a higher priority I'd argue than any security concerns. For more on that: https://brson.github.io/rust-anthology/ ... -safe.html

3. Rust's community is smaller, and has some serious concerns surrounding drama, doxxing, harassment etc. I'm not a fan of communities that are so schizophrenic in moderatorship or so corrupt they can't handle themselves appropriately.

4. What benefit does this offer? What problem does C++ really have for OpenMW?

5. Rust is not OOP. It cannot do most of the OOP-related things itself, especially classes or inheritance. That's a serious limiter.

Also, there's a difference between OSes, architectures, microarchitectures (uarches), ABIs, library support and other issues. As it stands, OpenMW can theoretically run (Without the launcher/CS) on any system that can build OpenSceneGraph and SDL AFAICT. Yes, other libs are needed and you need a recent G++ compiler, but that's not an insanely bad limitation. GCC is very portable. I could port OpenMW if I REALLY wanted to PowerPC32/macOS Leopard with some frustration, I bet.

Your proposal, even if just an honest question, would limit OpenMW to Linux/Windows/macOS (BSDs have poorer Rust support, as does Solaris, MorphOS, AmigaOS4, Haiku etc.) and basically x64/ARM. That may be an acceptable view of yours, but I'd say it's needlessly self-limiting.

[AnyOldName3]

Some of your information might be pretty out of date. PHP's been nearly completely pushed aside in favour of JavaScript (both getting the client to deal with things that were historically the server's job, and JS running on Node on the server, too) for over a decade, and no one's made a 32-bit-only x86 processor for a decade and a half. No one's made an effort to put Rust on that architecture because everything that runs it developed rust naturally by now thanks to corrosion.

The far fewer compilers argument is generally taken as a strength of Rust. There's only one implementation and it runs everywhere people want Rust to run, so there's only one interpretation of the standard you have to be compatible with to make things cross-platform. In the last eight years or so, Microsoft have been putting a lot of effort into making their compiler less weird, so this isn't as big a problem in C++ as it once was, but it's still not gone.

[BlueSkySystems]

I don't wanna get too OT here AON3, but I will briefly refute what you've said.

> PHP's been nearly completely pushed aside in favour of JavaScript (both getting the client to deal with things that were historically the server's job, and JS running on Node on the server, too) for over a decade

False. PHP is still used by 80% of the EN-speaking web for everything from Mediawiki, Wordpress, to 90% of forum software.

NodeJS is terrible, I have been in webdev for 15 years and I outright refuse to troubleshoot people who approach me about it. I tell them "Brand new site or go find someone else."

> no one's made a 32-bit-only x86 processor for a decade and a half

True for mostly consumer grade stuff, not gonna split hairs.

> No one's made an effort to put Rust on that architecture because everything that runs it developed rust naturally by now thanks to corrosion.

That would be fine /if/ projects weren't trying to migrate from a C base to Rust or if Rust was only a niche language. Unfortunately, that's simply not the case here. It's trying to /inherit/ the mantle of languages like C or C++, and not willing to inherit the responsibilities of those architectures is plainly unacceptable. I work on embedded systems and 20+ year old hardware at my job, telling a business that they need to spend millions to "upgrade" when doing so would have marginal performance or efficiency benefits is not going to ever happen.

Yes, you can argue this is all "cruft" but all too often I see people discounting legacy support with a bunch of handwaving. It makes little sense to me.

> The far fewer compilers argument is generally taken as a strength of Rust. There's only one implementation and it runs everywhere people want Rust to run, so there's only one interpretation of the standard you have to be compatible with to make things cross-platform. In the last eight years or so, Microsoft have been putting a lot of effort into making their compiler less weird, so this isn't as big a problem in C++ as it once was, but it's still not gone.

Well, outside of MS, non-GCC compilers for UNIX/Linux/BSD/Solaris/Whatever even historically weren't insanely different. Many of the issues with compiling C++ for Windows is not the fault of the compiler but moreso the OS. Windows' kernel has more in common with OS/2 or OpenVMS than it does Linux or UNIX, so of course it isn't going to compile out of the box without compatibility layer. Haven't coded for windows in ages, but I'm imagining that Windows still doesn't accept many UNIX conventions natively.

Anyways, AON3 I understand and respect your views on these things and that they don't line up with mine. My humble suggestion is not to pejoratively discount what others say or make sweeping generalizations about the computing industry. It's all about perspective and the computing industry is absolutely massive.

Thanks!

BSS