There has to be some kind of organization in order to present a coherent list of demands. Otherwise we end up with another Occupy Wallstreet where half of the people in the movement can't articulate what change they want to happen.
I would love to strike for better pay, but I'm worried that particular demand will only spread us thin and make it harder to get leverage. Obviously things are so fucked that we could come up with an endless list of demands. I want to make sure such a list doesn't explode and become a point of division.
That said, obviously a collective action is about the will of the people involved. So if there is a majority of strike participants that believes one of the demands should be related to pay (hopefully for increasing the minimum wage, not just raising the salaries of those already making 6 figures), that should be considered.
Regarding the derive macros, there are a few reasons these are required.
Rust does not have a language runtime (like Java). So certain features that would normally require reflection instead require an opt-in trait implementation. This is part of Rust's "zero cost abstractions" philosophy. You don't pay for code you don't need.
You get the benefit of being able to customize the behavior of those core traits. Rather than doing something simple (and wrong) for every type, like a byte-for-byte equality check, you get to define the behavior that is appropriate for a given type.
The derive macros are just a convenience. You are free to use "regular code" to implement those traits instead.
I think feminism is a perfectly appropriate word choice for the movement. The focus is on the fact that women are discriminated against, and that is a very specific scope of problems that need to be addressed. Calling it egalitarianism kinda loses the point and draws focus away from the actual problem. I.e. the movement is about solving problems, not about a hypothetical utopic end state. You could argue about what that utopia should look like forever, but the movement has already identified concrete issues that need to be addressed.
Anyone who nitpicks the word choice like in the comic is just not sympathetic to the issue and causing a distraction.
I guess I see what you mean if we want to get very technical about what a syntax extension is. But I think for the purpose of this discussion, it's reasonable to think of macro_rules! as a part of the Rust language. Practically speaking, it is syntax provided by the language team, not just users of the language who are free to extend the syntax by usingmacro_rules! to do so.
Enums are the best part of the Rust language IMO, so I'm not sure how you can view them as ugly. Having the choice to destructure something is fantastic. You generally aren't required to destructure every return value. Make sure you're using the ? operator as much as possible. If destructuring is getting in your way, it sounds like the code is not very idiomatic.
I can't really comment on your issue with nested if and match. Too much nesting is bad in any language; try extracting more functions and let bindings to make it more readable.
You can enable a clippy lint to deny .unwrap() if you're worried about it.
Sorry, I love Rust but I can't really agree with you here. They only showed a macro_rules!definition, which is definitely rust syntax. Lifetime annotations are relatively common.
I will concede that loop labels are incredibly rare though.
There has to be some kind of organization in order to present a coherent list of demands. Otherwise we end up with another Occupy Wallstreet where half of the people in the movement can't articulate what change they want to happen.