What's so bad about Rust?

[137ben]

I gather that many here do not like rust (the language). But what's so bad about it?

[Moonchild]

I think Rust is a mixed bag. Some good ideas, but at the same time I've been thinking "why did you need to make a new language for that?".

I think if you distil it down to a single "bad thing" then it is simply that Rust isn't a general-purpose programming language. There's limited platform support for the compilers, compilation is (painfully) slow, and essential things for larger programs like multithreading use, caching, packed data storage, etc. are generally so difficult to achieve that the usual response when asking for help with it is "don't bother to even try, just program it inefficiently and worry about optimizing later" (and that "later" never happens).
On top of that it requires dealing with an overly verbose and convoluted programming paradigm that isn't flexible, and often doesn't solve what it claims to solve. Rust also has a tendency to force you into achieving your goals with your programming in a very specific way, and if you decide to use a solution not 100% aligned with that it will absolutely scream bloody murder at you or flat-out refuse to work/not provide any possible solution. It then boils down to the dev finding workaround upon workaround and having to fight the language itself instead of it supporting the dev in achieving what they set out to do.

If you're looking for a high-level language for fairly simple programs achieving something the Rust developers envisioned as potential use case, where you can build something from the ground up, then it may be genuinely useful and do exactly what you want -- if you can spend a ton of time to figure out what you need (because documentation has been pretty bad last I checked). But overall it seems to just miss the mark, and all the energy spent on it would have been better spent improving existing and established high-level languages, IMHO.

[jobbautista9]

For me it's the horrible compilation speed, the lack of a stable ABI, the "everything should be its own crate" mentality with its pushing of its own cargo package manager (there's a joke in the SeaMonkey IRC where they were able to remove X lines of code because of Rust, in exchange for 100 more dependencies), though to be fair with Rust it's not the first language to do that (but I still hate that idea with passion), and I guess its community just being extraordinarily annoying with its RIIR shit for example (though admittedly we can ignore that).

[Nuck-TH]

Also worth noting that (at least last time i checked) it lacks stable standard(which C and C++ have) and truly universal and flexible standard library. Feature creep, breaking changes and limitations of standard library implementation doesn't really align with language for reliable systems it wants to be.

[frostknight]

Also worth noting that (at least last time i checked) it lacks stable standard(which C and C++ have) and truly universal and flexible standard library. Feature creep, breaking changes and limitations of standard library implementation doesn't really align with language for reliable systems it wants to be.

And on top of everything said above, you can't make your own rust compiler without their permission due to their hideous trademark restrictions.

Its not a free software or open source programming language. Yet there are so many people who are throwing aside this warning and acting like it is.

This alone bother me and then there is the rust crowd is toxic and its a rolling release development...

And last but not least, if you need training wheels to prevent you from making mistakes, that C wouldn't prevent, it means YOU ARE THE PROBLEM, NOT THE PROGRAMMING LANGUAGE...

This topic is well... one that I cannot wrap my head around. I despise rust for these reasons above. It isn't what they claim it is and its effectively non-free due to their dipshit trademarks.

I cannot stand them honestly nor do I understand why people blindly support it as if it is something awesome.

[jobbautista9]

Its not a free software or open source programming language. Yet there are so many people who are throwing aside this warning and acting like it is.

Open-source is only concerned with copyright (and free software would unquestionably be too if it's not for the FSF dictating that a software is not free if you don't allow people to redistribute it with a fee under the same name). Trademarks are irrelevant.

Having said that...

And on top of everything said above, you can't make your own rust compiler without their permission due to their hideous trademark restrictions.

If you're using "rust" in the name of the compiler then the trademark policy actually allows this. You are not modifying the official Rust compiler, and something like "gccrs" or "GCC Front-End For Rust" would fall under "Stating accurately that software is [...] compatible with the Rust programming language" in the "Uses that do not require explicit approval" section.

[moonbat]

, if you need training wheels to prevent you from making mistakes, that C wouldn't prevent

Great, you just invalidated every garbage collected language with that statement. Not having to keep worrying about memory allocation and deallocation is a big plus for enterprise applications that as it is have to deal with complicated business logic without this as well. There are appropriate tools for every use case, else if all you have is a hammer then everything looks like a skull

[Nuck-TH]

Great, you just invalidated every garbage collected language with that statement. Not having to keep worrying about memory allocation and deallocation is a big plus for enterprise applications that as it is have to deal with complicated business logic without this as well. There are appropriate tools for every use case, else if all you have is a hammer then everything looks like a skull

Off-topic:
Automatic memory management with GC is more of different paradigm with its own set of pitfalls than crutch/"training wheels" imho.

[moonbat]

One pitfall is you still have to dereference unused objects to make them available for garbage collection, else they will continue to occupy memory.

[Basilisk-Dev]

One of the primary reasons I am not fond of the Rust programming language is its lack of portability compared to languages like C. While Rust offers modern features and safety guarantees that are attractive for many applications, it falls short when it comes to supporting a wide range of operating systems and CPU architectures. This limitation is primarily due to Rust’s reliance on the LLVM compiler infrastructure, which does not support as many platforms as the traditional C compilers do.

C has long been celebrated for its portability. Its compilers are ubiquitous and can be found on virtually every operating system and hardware platform imaginable. This universality allows developers to write code that can be compiled and run on an incredibly diverse set of environments without significant modification. For someone like me, who enjoys tinkering with alternative CPU architectures and operating systems, this level of portability is essential. It means that I can experiment freely, porting my code to niche systems or custom hardware without being hindered by the limitations of my programming language.

This lack of portability is not just an inconvenience—it fundamentally restricts the scope of projects that can be undertaken with Rust. For instance, when working on a custom operating system or experimenting with a novel CPU design, the absence of a compatible Rust compiler means that developers are forced to either invest time in porting the compiler themselves or abandon Rust in favor of a more portable language like C. This scenario is less than ideal, as it places unnecessary hurdles in the way of innovation and exploration.

Even within mainstream operating systems like Linux, Rust can present challenges on less common architectures. Developers targeting platforms such as MIPS, SPARC, or other specialized hardware may find that Rust lacks the necessary support to build and run applications effectively. This situation contrasts sharply with C, where robust compiler support exists for nearly every architecture, thanks to decades of development and widespread adoption.

Moreover, the portability issue affects not only the act of compiling code but also the broader ecosystem of libraries and tools. Many Rust libraries may not be tested or supported on less common platforms, leading to compatibility issues that require additional effort to resolve. In the world of C, the extensive and mature ecosystem often ensures that libraries and tools are readily available or can be adapted with relative ease.

[Moonchild]

One pitfall is you still have to dereference unused objects to make them available for garbage collection, else they will continue to occupy memory.

Yet, at the same time, it has the "lifetime" concept which often gets in the way because things are released too early or can't be carried across threads. So the question then becomes: do you have to dereference or not? Will it be released while you want it to remain alive? Or will it leak? Not sure if it solved anything there.

[137ben]

Thank you, all. Your responses helped clarify things considerably.

[frostknight]

Oh, btw, I forgot to mentiom one other gripe, there are a group of people out there trying to rewrite everything in rust.

That is another and final reason I detest rust.