RustSupremacist

One of the banned individuals was indeed not serious: https://xcancel.com/Malix_Labs/status/2079172393105227839

I am guilty in the Rust community of being too obsessed with Zig. I don't know why. There are many other languages mentioned in a negative way but for some reason, mentioning Rust makes people very sensitive. Meanwhile, we have no problem disparaging other languages to support Rust. For those of us who have Rust and are happy with Rust, why do we need to concern ourselves with another language and their issue tracker? This happened when it was announced that TypeScript was being rewritten in Go too. I want the Rust community to be better even if it means not interacting with other programming languages. There is nothing to gain acting like bullies and thugs.

This reminds me that the Rust Foundation is a 501(c)(6) and not a 501(c)(3) like the Zig Software Foundation. To me, the Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances.

501(c)(3) organizations are non-profits that include charities, whereas 501(c)(6) organizations are non-profits with less strict requirements. Both are tax-exempt federally, but 501(c)(3) organizations have higher financial transparency requirements and higher restrictions on political activity (which qualifies donations to 501(c)s as tax-deductible).

The Rust Foundation is a 501(c)(6) and not a 501(c)(3). The Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances. The Rust Foundation should change their governance structure to a 501(c)(3) instead of a 501(c)(6).

Donations to the Zig Software Foundation largely go to contributors to the language. Meanwhile, donations to the Rust Foundation largely go into pockets unknown.

The key difference is that the Rust Foundation is a 501(c)(6) and not a 501(c)(3). The Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances. Follow this example for the greater good.

Rust needs good Qt bindings. None of the existing projects will ever reach Qt. Rust. Cargo. Qt. Go did it with https://github.com/mappu/miqt. Zig did it with https://github.com/rcalixte/libqt6zig. When will Rust do it? The time is now.

There are bindings for Go (https://github.com/mappu/miqt) and Zig (https://github.com/rcalixte/libqt6zig) but not for Rust. We need bindings like these for Rust.

This is not what the people want. Understand that. Give us Rust and Qt. Why be so focused on trying to sell something that doesn't measure up? Even beta Bridges is better than Slint. Take the advice and put the energy to better use for the good of Rust.

We need to go back to when the front page of the site was only Rust posts.

Rust is perfect. Too perfect for the fascists behind Ladybird. https://drewdevault.com/2025/09/24/2025-09-24-Cloudflare-and...

Leave Rust for the non-fascists.

The GUI situation for Rust is dire. We are still not GUI yet! Even if Rust isn't the best for GUI, the opportunity is still there. Qt is the best option. There isn't a second option. Don't let Go and Zig have bindings for Qt without Rust! Only Rust. Only Cargo. No QML. No C++. No markup. No immediate mode. No dead projects.

The most charitable interpretation of this is that the Reddit mods should stick to Reddit. If they had, this wouldn't have reflected so poorly on them.

This attitude is why the project has toxic maintainers from Germany to China: https://xcancel.com/QULuseslignux/status/1918296149724692968

This author is not someone who should be reporting on Rust especially in the kernel: https://www.youtube.com/watch?v=gVC1gp2PS8U&t=1538s

The GUI situation in Rust is dreadful: https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...

Rust is simply not meant for GUI-based data design but I still want Qt in Rust. That's it. Not QML or Slint or egui or Tauri or gpui or Iced. No markup at all. None of the immediate mode things. No double and triple languages like this C++ mess. Definitely not GTK or the other non-imperative subpar things. There is one option. Until there is more than one, Qt is the best. No one else is worried about this missed opportunity.

[flagged]

The author is not a programmer and has written something he hopes to be a self-fulfilling prophecy. We don't need misinformation and cope. Rust deserves better than this. The damage from the correction that comes later will do so much harm.

What does it say about your latest project that it attracts the most toxic types from Germany to China^? Are you even aware? Do you consider this "building the right group of talent" for your project?

^https://xcancel.com/QULuseslignux/status/1918296149724692968

This highlights the value of having non-profits as a 501(c)(3). The transparency about Hack Club is refreshing.

The Rust Foundation is a 501(c)(6) and not a 501(c)(3). The Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances. Follow this example for the greater good.

This is a total victory for Rust. Zig was making progress before this. Now the project is going to black hole itself in the most tone deaf and spectacular way possible. Not even a mirror? Way to accept total defeat.

This post has brought out all of the bots and sock puppets. Where are the moderators to act against this site manipulation?

This would be great if it weren't such a hasty generalization. A comparative analysis against alternative approaches like continued hardening of the legacy code base would have been better to read through. This suggests there is no middle-ground to be had which we know to be false. And all this while oversimplifying legitimate engineering trade-offs like build system complexity and developer retraining costs.

Relying on Google as a credible institution rather than independent verification results is what can only be described as self-evident truth. This is corporate tech evangelism that only benefits Google.

Why does the article avoid adoption barriers due to Rust's steep learning curve? Why does the author gloss over maturity gaps in the toolchain? Why isn't there feedback included from the maintainers of the critical components like HALs and other drivers?