Rewrite Rust components in C (yes, seriously.)

(#996) Feature Declined meta performance

Thread

Comment by @Speykious
RexSystem 1 vote originally by @Speykious on GitHub 2 replies
Rust is less compatible than C, meaning users (such as those running BSD, plan9, etc) may be unable to run it.
Rust supports FreeBSD officially as a Tier 2 target, but what matters most in Fluxer's case for Rust used client-side is the WASM target (also Tier 2), because that's what libfluxcore compiles to. So if your platform runs a Chromium or Firefox derivative, it will run Fluxer. https://doc.rust-lang.org/nightly/rustc/platform-support.html If the platform is so niche that it can't run a browser, imo it's not worth supporting in the official client and you might as well write your own.
you trade performance, reliability and user trust for real-time automatic memory management
This is true of garbage-collected languages. Rust is not garbage-collected, it simply gives you compile-time rules to manage memory yourself safely, which you can extend using unsafe if you need to. The trade-off is more time spent checking the code at compile time, not runtime performance. Though the Rust compiler mostly spends time generating code and handling generics. At runtime, it is as performant as C and more in some cases. There is no world in which C is safer than Rust. It always baffles me that people always try to attack the least attackable aspect of the language, the one that's empirically proven, when it has actual real problems that people could be talking about instead. (I'll also note that most Rust devs don't like being associated with cryptobros, but unfortunately we're stuck with the state of the job market. It is what it is.)
Comment by @ctudor0
RexSystem 1 vote originally by @ctudor0 on GitHub
Man, stop. Rust is not even sound... Rust model is broken. There are Github issues related to that. The company control is real. The language specification is non existent and there are million other issues with the language. There's no ABI, you can't make shared libraries without C. Don't tell me the opposite because I use Rust very very often. The only reason you're here is because of this: "Member of the Rust Evangelism Strike Force. Also I hate Java" copied right from your profile. That invalidates all your arguments. You people gotta stop with the sectarism.
Comment by @Speykious
RexSystem 1 vote originally by @Speykious on GitHub
I'm not sure why you took that thing from my profile so literally. It's a meme, chill out. I'm here because I looked at Fluxer recently and it seems like a really cool project with lots of potential. "Rust is not sound", or rather, "Rust has soundness issues" is a valid concern, but when every single compiler from every single language out there also has soundness issues and bugs, it doesn't really help the discussion. Instead look at Google Security reports like this one to get a feel of the gains you get with the language compared to C++ for example. At the very least it would give you the big picture of general gains or losses you get when using it at scale. And if you're so untrusting of Google that you might suspect everything in that article is fabricated, then you can look at how other companies or people used the language, like Discord replacing Go with Rust, or the Linux kernel having experimented with Rust and concluded it was worth continuing in that direction. And yes, there's no ABI, but that's a problem for shared library integration of Rust libraries with other Rust projects. Not really for anything else. The C FFI works just fine and it's not hard to make Rust bindings of C libraries, it's just a bit more unsafe than ideal. But also, for a project like Fluxer, that's kinda irrelevant. The important thing is that it all compiles to WASM. Here, I'll give you two other ones for free: while Rust has a few UI frameworks and a quite popular game engine (Bevy), it's still not quite ready for GUI apps for a lot of people (though the Cosmic desktop is using it fine), and the same can be said about game dev. I'm making my own UI framework in Rust despite this though. And of course that's not to mention the amount of bloat that generally comes with the ecosystem of dependencies on crates.io, which blows up compile times more than necessary. It's something that can be fixed by essentially reinventing the wheel again but with better API boundaries, something I do all the time, but I'm only one dev. At least I'm glad stuff like jiff now exists to replace chrono, but I hope one day we also get a stable windowing library that doesn't pull 100 transitive dep crates (similar to miniquad), because there's no reason it can't be done.