Rewrite Rust components in C (yes, seriously.)

(#996) Feature Declined meta performance

7mo agoby RexSystem edited originally by @zleepyzeezee on GitHub

Problem

Rust is a programming language that is being funded by major big-tech companies such as Google, Microsoft and Mozilla, (CorpoSlop, as they say.) which means it is under their control, meaning at any time things could change, not only that, Rust is less compatible than C, meaning users (such as those running BSD, plan9, etc) may be unable to run it. Also, Rust has a reputation for being an entry for bad programmers and AI programming (which your users will hate), being "memory safe", you trade performance, reliability and user trust for real-time automatic memory management, whereas managing memory by yourself is almost always more performant and safer. C is a much safer, faster, and more trustworthy alternative to Rust, and, to drop the extremely professional writing, me, my friends and other users like us would probably be much more receptive to moving to Fluxer. (I think I'd still use it even with Rust, but C would be better, :3) I believe many people (including me and my friends) would also be happy to help with writing C code too. :3

Proposed solution

C replacements for Rust components :3

Notes (optional)

Even if it's a long range goal, it'd be highly appreciated by many, in my opinion :3

History

36 comments

Sign in with Fluxer to comment and vote.

RexSystem 1 vote 1d ago

This was marked shipped, but nothing was rewritten. The closing note said it would not be done and the author later withdrew the request.

RexSystem 1 vote 7mo ago originally by @shininghero on GitHub 2 replies

Intriguing, but I don't think rust needs to be tossed entirely. As a counterpoint, support for Rust in the Linux kernel has matured enough that it's no longer considered experimental. If the core developers consider it stable and safe enough for the kernel, it's probably fine here in Fluxer.

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

Yeah, that's valid, though I really hate that Rust is in the Linux kernel it's only bits and pieces. My friends are a lot more hardline though, some have moved to BSD over it, XD

RexSystem 1 vote 7mo ago originally by @shininghero on GitHub

To each their own, but I'm going to assume that the literal makers of Linux itself are far more qualified to make decisions on languages, and the same goes for the fluxer dev.

RexSystem 1 vote 7mo ago originally by @Atrophied on GitHub 2 replies

This feels like a troll post.

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

It's really not a troll, I swear; I just really dislike and distrust Rust. Fluxer's real cool but Rust is a big con for me...

RexSystem 1 vote 7mo ago edited originally by @SafeShows on GitHub

@zleepyzeezee What do you dislike about Rust and why do you not trust Rust? From my POV this is a troll post

RexSystem 1 vote 7mo ago originally by @ctudor0 on GitHub 3 replies

I fully agree with using C instead of Rust. That's definitely a really good idea to avoid corporate control. I also think it's generally a better idea to keep the number of different languages as low as possible. I'd say at max: Typescript, Go, C and Erlang (if really necessary for hot code swapping). I'm happy Gleam code was rewritten to Typescript.

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

Good point, I didn't really mean it has to be strictly C, I just really like C and others I know agree, but as long as we're staying away from big corpos, that's fine with me :3

RexSystem 1 vote 7mo ago originally by @ctudor0 on GitHub

Yeah Go should also do the job for example.

RexSystem 1 vote 7mo ago originally by @whimbree on GitHub

Go is a strictly less performant language than Rust since it uses garbage collection. Rust doesn't use any garbage collector, and has a much smaller runtime than Go. Rust also compiles down to WASM for use in the browser and this is well supported. Go has some WASM support but it's still experimental: https://go.dev/wiki/WebAssembly Also, Go was created and is owned by Google - I'd argue it's far more corporate entrenched than Rust.

RexSystem 1 vote 7mo ago originally by @oax90 on GitHub 4 replies

Right now in the refactor branch Rust is used only in the client for a simple purpose. Is there really a need to keep dependency on Rust for that? I rather keep it full TS or use Go or C.

pub use animation::is_animated_image;
pub use apng::crop_and_rotate_apng;
pub use gateway::decompress_zstd_frame;
pub use gif::crop_and_rotate_gif;
pub use static_image::crop_and_rotate_image;

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

So simple I think TS could do it without much of a hit to performance either XD

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

Image decoding and processing is a quite resource-intensive task, so it makes sense to dedicate that to a lower level language. Given that it all needs to run on the browser, it has to be compiled in WASM, and Rust is kind of the best tool for that job. C could also do that job, just not as well.

RexSystem 1 vote 7mo ago originally by @ctudor0 on GitHub

What do you mean not as well? You gotta be kidding. All image manipulation libraries are C. Both C and C++ can be compiled to WASM without any problem. Same goes for Go here. Don't act like Rust is the only thing that compiles to WASM.

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

No, I'm not kidding. Rust is by far the best language when it comes to targeting WASM. It is extremely straightforward to just make something compile to WASM in Rust. The same cannot be said about C which doesn't even have a package manager or standard build system. You can get away with a lot by doing unity builds of course, and it probably wouldn't even be that bad if set up correctly, but let's not pretend it's better than Rust for the task.

RexSystem 1 vote 7mo ago 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.)

RexSystem 1 vote 7mo ago 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.

RexSystem 1 vote 7mo ago 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.

RexSystem 1 vote 7mo ago edited originally by @electron271 on GitHub 2 replies

Rust is a programming language that is being funded by major big-tech companies such as Google, Microsoft and Mozilla, (CorpoSlop, as they say.) which means it is under their control, meaning at any time things could change

The Rust Foundation (what companies are members of) has no say over Rusts direction and they are separate entities. Typescript is also owned by Microsoft, which you have suggested as another possible alternative in https://feedback.fluxer.com/p/996/c/2803 and is also primarily what the project is made with.

me, my friends and other users like us would probably be much more receptive to moving to Fluxer. (I think I'd still use it even with Rust, but C would be better, :3)

If only 1k lines of Rust used to speed up image processing is enough to influence you and your friends to not use Fluxer, then Fluxer may not have been for you in the first place given how much it utilizes languages/technologies that actually match parts of what you have said (such as Typescript, Go, Electron, etc).

RexSystem 1 vote 7mo ago originally by @ctudor0 on GitHub

"has no say over Rusts direction and they are separate entities", that's very naive to think. Can you prove that? No! If they request features or changes in the language, they'll get them. They're paying. Same thing has been said with the Kernel which is obviously not true. Lastly, we people can't pick anything else, because there's always a member of the sect that comes, hijacks the projects with 5 lines of Rust code that don't do anything just because the goal is to get Rust as a dependency into every project. We also have our views and words to say. You're not the only ones.

RexSystem 1 vote 7mo ago originally by @electron271 on GitHub

Can you prove that?

Yes! Rust features are done via a RFC process, where RFCs are discussed by the Rust team which is primarily composed of volunteers from the open-source community. For smaller changes this is the review process which also requires extensive review by the team. There is also an MCP process for medium-weight changes. There is no way for a company to force features/changes, and if you have any examples of this EVER happening, providing those would be much appreciated. You also haven't addressed my point regarding Go/Typescript, the first of which you suggested. What could they possibly be wanting in the Rust language that would be even more dangerous than anything Go/Typescript has already gotten, apart from the vague "at any time things could change".

Lastly, we people can't pick anything else, because there's always a member of the sect that comes, hijacks the projects with 5 lines of Rust code that don't do anything just because the goal is to get Rust as a dependency into every project.

There isn't some "sect" of people who are trying to force rust into every project, people use Rust because it is currently the best at various tasks such as WASM in this case.

RexSystem 1 vote 7mo ago edited originally by @Chailotl on GitHub 3 replies

Wow, just wow. Where do I even begin with this?

Rust is a programming language that is being funded by major big-tech companies such as Google, Microsoft and Mozilla

And? This is a nothingburger of a statement. Many of the languages used by Fluxer are sponsored by these companies too.

Typescript
- Developed and maintained by Microsoft
JavaScript
- Major code contributions from Google and Meta
Python
- Sponsored by Google, Meta, Amazon, and Microsoft

which means it is under their control

This is patently false; as previously stated by electron271, the Rust Foundation does not decide what technical features or changes happen to the Rust language, and they have an RFC process for discussing Rust features, and the Rust team is "primarily composed of volunteers from the open-source community".

Rust is less compatible than C, meaning users (such as those running BSD, plan9, etc) may be unable to run it.

As previously stated by Speykious, Rust does in fact officially support FreeBSD, but this ends up being irrelevant as Fluxer is an Electron app which uses client-side Rust code on the WASM target. If your OS can run Chromium, it is supported by Fluxer.

Rust has a reputation for being an entry for bad programmers and AI programming

What? This isn't an argument, this is an ad hominen.

being "memory safe", you trade performance, reliability and user trust for real-time automatic memory management

This displays a fundamental misunderstanding of how Rust and its borrow checker work. Rust is not slower than C. Safe Rust may be slower than C, but you can write unsafe Rust to achieve performance parity with C. The number of performance-critical situations where you need to write unsafe Rust is vanishingly rare, if you even need to write your own unsafe Rust in the first place as many open-source libraries have already handled all the common situations. Rust does not trade away any reliability. If anything, memory safety grants you more reliability by making memory leaks impossible. It also nudges you to write better code in the first place, rather than letting your reference graph (how and where memory is allocated and stored) become a convoluted spaghetti mess. I don't know what your point about "user trust" is supposed to mean here. Rust's memory safety model is not "real-time". It is compiled.

whereas managing memory by yourself is almost always more performant and safer

It is never safer than Rust's borrow checker, which is based on formal mathematical principles to guarantee memory safety at compile time. In other words, it is mathematically proven to be memory safe. It is also never faster than Rust, which still lets you write unsafe Rust to achieve performance parity with C.

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

by making memory leaks impossible

This is actually the one memory issue that Rust doesn't solve. In fact, leaking memory is completely safe! Not that any other programming language can really solve this though, since it requires solving the halting problem... (But of course, stuff like use-after-tree, double-free, buffer overflow etc. are impossible in safe Rust.)

RexSystem 1 vote 7mo ago originally by @Chailotl on GitHub

That's a mistake on my part, I was trying to come up with the umbrella term to describe memory safety problems, and memory leaks is what usually comes to mind being the most transparent problem to users

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

Yeah. It does prevent dangling-pointer-induced memory leaks, to be fair. The two ways I can see Rust leaking memory is if you call leak explicitly, or your code is a smart pointer fest of potentially cycling Rcs/Arcs... Not a lot of cases really, especially since the latter is an antipattern and people usually don't code like that.

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP 5 replies

Thanks for all the input, seriously. While I still don't like Rust, you all come from good spots and I apologise for the amateurish hit-piece parts of the first post were. I wrote it in like an hour right before I actually signed up for Fluxer because I wanted to skim through the code first. I really like this project and I didn't mean to cause such an uproar between Rust advocates and detractors. I didn't mean to make it sound like Rust is entirely a deal-breaker for me, I just simply don't like it. It's fine if a program uses it and well. All of the Rust programs I've used before just really sucked, haha, but Fluxer is alright, :3 It's also really scary to me 'cuz the ways Rust programs are structured are very visually different to what I'm used to so I am just completely lost on stuff like compiling and writing programs in it. (Crates 'n such. I'm used to C libraries with .h extensions, etc. X3) Maybe I'll learn Rust to help with this project despite my apprehensions :3

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

Update: where'd all the rust go

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

All of the Rust programs I've used before just really sucked, haha, but Fluxer is alright, :3

Aw that sucks :( Do you remember what they were? Personally whenever I use one it tends to be pretty good. I use tokei all the time for instance.

Maybe I'll learn Rust to help with this project despite my apprehensions

Never hurts to learn a bit! At least if you end up still not liking it you'll have better reasons B) The official resources are excellent to get started. https://rust-lang.org/learn/

RexSystem 1 vote 7mo ago originally by @zleepyzeezee on GitHub OP

Aw that sucks :( Do you remember what they were? Personally whenever I use one it tends to be pretty good. I use tokei all the time for instance.

It was jgenesis, a MegaDrive emulator a ROM hack I wanted to play recommended, the moment I booted it up it was around 2 - 10 FPS the entire way through, the worst and slowest emulation experience I've had. It might have been just leveraging accuracy over performance, but I've used ares (written in CXX) which is known for it's accuracy and it ran flawlessly on my machine, so I just assumed it was Rust, seeing as it was the only difference I could tell that would matter.

RexSystem 1 vote 7mo ago originally by @Speykious on GitHub

I see. Yeah that's probably a bug then. I don't think any Rust dev would be tolerating an experience of 2-10 fps for something that isn't known to have stutters on retro machines. If it was recommended to you then that person is probably having a great experience as well. If you try tokei and compare it to clock, you'll probably have the opposite experience. Though those projects are much smaller in scope :p

RexSystem 1 vote 6mo ago originally by @zleepyzeezee on GitHub OP

Update on my Rust escapades: I got alacritty and wow does it work well, checks all my boxes :3 Even though I prefer C, Rust isn't all that bad :3

RexSystem 1 vote 5mo ago originally by @zulc22 on GitHub 1 reply

Rust and Cargo are much less burdensome for people to set up than compilers and build systems for C.

RexSystem 1 vote 5mo ago originally by @zleepyzeezee on GitHub OP

While I would disagree and say that it is better to be proficient in something hard, Fluxer uses Rust for a valuable purpose and am not going to make a fuss about it anymore.

RexSystem 1 vote 5mo ago originally by @jessielw on GitHub

Just no

RexSystem 1 vote 5mo ago originally by @zleepyzeezee on GitHub OP

Hallo! Sorry for not doing this earlier, but I've decided that Rust is fine, and I won't be making further attempts to promote C's usage over Rust in Fluxer. I see it's purpose here, and am fine with it. Thank you all for bearing with my lack of knowledge on the subject, and not being too feisty over it. Bai-Bai!