A genuine question, why do people hate rust

According to the surveys of Stackoverflow, Rust is the most loved language.

I don't hate it. If developers say its good I'll believe it, e.g. the StackOverflow survey.

For me, I didn't like the syntax, it's not readable compared to other languages like JS, or PHP

@Sid2006 yea true and the ownership concept is new, i like it tho

Do they?

@ScriptCoded mostly on weird discussions board like 4chan

I don't think anyone whose opinion matters hates Rust. People either tend to hate Rust fans that want to rebuild everything in it, or distrust the Rust foundation for obvious reasons.

@lorentz what obvious reasons

There are of course people who don't actually have a plan for the structure of the data they have and so they're afraid of static typing, there are a lot of people who are opposed to building ownership trees because they learned to code with a GC'd language, and there are a ton of other personal reasons to prefer something else.

Most of these people are aware that their preferences are personal, though.

@lorentz yea true most reasons should be personal, since it's a matter of personal taste

Rust has no ISO standard, so Rust is whatever the one and only Rust compiler happens to do.

Cargo is an exceptionally bad idea that only could have happened in a web company where people were already used to comparable badness from NPM.

Rust ignores decades of deployment and bakes everything into one executable just for developer convenience. Same problem as with Snap or Flatpak stuff. A dependency has a security flaw? Yeah, you're not done with updating that dependency, you need to update every fucking application.

Rust is in a weird spot where it's unappealing to C++ programmers because C++ has already paid the ecosystem ramp-up cost. Rust is not a choice for C programmers, either, because if they wanted a hyper-complex kitchen-sink language, they'd have gone with C++ long ago.

@blackpandan Bullet list of key episodes in the Rust Foundation drama:

- The entire moderation team had resigned a while back because they felt they had no oversight on the core team. In response, the foundation transitioned to a "loose herd" governance model realized in a single group chat with no policies whatsoever

- published a draft trademark policy that essentially bans mentioning the language in the name of an organization or project without the foundation's approval (not something you want to do when people already don't trust your judgement)

- managed to invite an esteemed researcher to hold a keynote talk at RustConf, then downgrade his talk without realizing that they did so until the speaker withdrew altogether in response

Here's a decent account of the keynote fiasco with links to the previous ones and other accounts. I'm not sure how up-to-date it is as the author has been on hiatus recently:

https://fasterthanli.me/articles/...

@lorentz

Magnificent job there, man.

Yeah, in short, I don't hate rust but I hate zealot rustards.

Not hating it. But here are some concerns :

1) There is only a single compiler. No standard not even a formal specification. This should be a nogo for a serious project. Maybe this will be better in the future, but as long as there is no formal specification, don't use it.

2) The rust foundation (see comment from @lorentz)

3) Suggested default indentation style is hard to read and slightly more error prone than a good indentation style. Most docs use this style.

4) It is "invading" spaces where it shouldn't, like the Linux kernel, because of point 1). Adding such dependencies are a stupid idea (but that isn't the fault of rust, it is the fault of the Linux maintainers).

@happygimp0 There is a formal spec, it just only has one implementation. You could say that a spec with only one implementation is not a spec, but multiple implementations don't emerge until there's a concrete use case that rustc cannot meet and that's easier to achieve in a separate implementation than just by contributing to rustc.

I understand the concerns about multiple implementations but the vast majority of modern languages have a single leading implementation and alternatives only emerge for unusual runtimes, and hardly ever compete with the main implementation because it's uneconomical.

The market changed. Languages are complex. C++ has multiple compilers but only because CLang emerged in the develoent of LLVM, which is actually a large part of the implementation of dozens of languages? How's that for resilience through competition?

Actually, if we count backends as fractions of an implementation then Rust has somewhat over one because they have a GCC backend now too.

@lorentz Where is the formal specification? I found a reference "The Rust Reference", which say "...should not be taken as a specification for the Rust language." Here: https://doc.rust-lang.org/stable/...

There are a lot of C compilers, multiple C++ compilers (not just gcc and clang), multiple interpreters for Python and multiple interpreters for shell scripts (they often have some unique features but it is possible to use the same script in all of them), and there are multiple Java Script interpreters. Even go has multiple compilers.

See also: https://en.wikipedia.org/wiki/...

Avoid single point of failures for productive applications where possible.

@lorentz A specification is not "how do you program in Rust". A specification is a set of definitions and rules that allows a clean room implementation of another Rust compiler without ever resorting to the existing rustc in any way, shape, or form.

@happygimp0 On top of that, how does one even tell a compiler bug from a language feature when there's no standard to refer to?

@happygimp0 I was thinking of the RFCs, but then I realized that although an acceptable Rust RFC meets the standard of a normative spec, they only describe changes to a base language which isn't defined, and therefore all the RFCs together still don't comprise a normative spec.

honestly after exploring go it's next on my list. i dont love or hate it, because i don't know it. I think ultimately (sadlly and admittedly) its performance for most tasks is better than go!

@Fast-Nop i have problems with cargo only in name squatting and low quality crate. What else are the problems?

@Fast-Nop And I think complexity is not comparable to cpp since Rust not including formal OOP(other than some enummagic), it is really simpler than cpp to me.

@aviophile Making dependencies "easy" doesn't solve the problem, it makes it worse.

Also, relying on an internet service for building shit is just so backwards that it hurts. Sure, you can set up your own cargo server and fuck around with that, but then you even lose the "easy" part and are just left with a monstrous dependency liability chain for everything but a hello world.

@aviophile Rust follows the same approach as C++ - if there is a problem, make the language more complex. Kitchen-sink language. By contrast, in C, you don't solve that via bloating up the language - you solve it via C code.

Something like Zig would be an idea that might appeal to C programmers, but that doesn't even have the hype train.

@Fast-Nop How are monster frameworks like Boost preferable to large dependency trees? Because unless your idea is making every programmer write an implementation of every invention not included in your STL with varying degrees of correctness, the sole alternative to easy dependency management becomes a small group of megaframeworks that the entire ecosystem hinges on.

@lorentz

I tend to think of boost as c++next/unstable and c++old/backports apt repos XD.

Besides, except some very system dependent ones, most are header only and can be used independently of others.

@lorentz Because Boost does not pull in recursive dependencies by not even god may know whom like in the NPM world - and, since Rust originated in a web company, also Rust.

An individual dev may choose, but only as far as the ecosystem allows it - and in such an ecosystem, there is hardly any even just medium sized library without a whole rabbit hole of dependencies because dependencies are easy, even recursive ones.

In turn, that's because most devs don't understand that dependencies are at least as much of a liability as an asset - and when you make that easy, it's exactly like in the meme I posted.

Also, as the prev comment said, Boost is next gen STL anyway, at least for the parts that turn out to be good.

@Fast-Nop I happen to think Rust is in a good place when it comes to abstraction and safety. But in my use, I try to stay away from iterable functional programming but I still enjoy not handling index based traverse for example.

Dependency hell is disgusting obviously, ggez game engine have 286 dependency in total.

@Gaha fuck off, spammer!

@Lensflare Thanks, my -- privileges had been revoked after I nuked 2-3 spammers like this