Well, if you don't get that someone else might see something as a flaw then perhaps you wouldn't understand that you may be defending a bad design choice.
I use Rust. There's a bunch of things I do not like about Rust. Its macro language is nigh on unusable. A macro language should be an expedient; it should allow you to get textual things done, committing necessary atrocities along the way knowing that the result must still pass muster with the compiler. It isn't supposed to remind you of a 61A midterm.
I like the safety and that is why I use Rust. I don't get adding functional programming to a systems programming language.
M4 is a standard POSIX utility and it's Turing complete. It's difficult to out-class recursive string macro expansion for sheer simplicity and sheer ability to confuse the heck out of yourself.
Alas, while it's a mandatory POSIX utility (AFAIU), some Linux distributions have saw fit to remove it from base installs.
I never said Rustaceans don't see flaws or that they don't defend bad choices. But I've never seen someone say "if you don't think so, then you Just Don't Get It" or any variant thereof in the Rust community.
It exists, although it's often phrased more kindly. For example, complaining about lifetimes is often met with a comment that you probably don't understand them yet.
I'm prefacing this by saying I think Rust is a very well-designed language, and AFAIK the best-designed language that currently exists in its problem space. Nevertheless there are aspects I'd consider design flaws and that fans have been known to dismiss with hand-waving or condescending lectures about type theory. That's a human problem, very much not a problem with the Rust community; in particular I'm quite impressed by how polite and helpful members of the Rust core team are — and not just Steve Klabnik — in every interaction I've seen them in.
1) The syntax is pretty bad; I would put it around the same level as Perl. It's simultaneously ugly, verbose and cryptic. It's especially indefensible given the obvious ML influence on the language. The superficial similarity to C++ syntax is more misleading than helpful and I think actually increases the learning curve.
2) Like the other guy said, the macro system might be technically impressive, but I feel like you shouldn't have to be some kind of Lex/Yacc guru to write or even read a macro definition. Sure, it's fully type-safe, but so is template metaprogramming — compared to which Rust macros somehow manage to be even less readable. There should at least be an easier syntax for simple, C-like macros.
Ok, they're aimed at a different problem space than C macros — they let library authors create sophisticated DSLs — but my impression's the current consensus is "non-idiomatic embedded DSLs considered harmful." Also, Rust is soon to have at least two other macro languages (attributes, and generics with specialization and value parameters), which is a whole lot of cognitive overhead to introduce.
3) All the `.iter()` and `.iter_mut()` is verbose and could easily be inferred from context by both humans and the compiler. If it truly must be explicit — and allowing implicitness as an option doesn't preclude allowing explicitness as well — then introduce new method call operators to go along with the dot operator.
4) I don't think there were compelling enough reasons to abandon the most technically amazing achievement of C++ compilers: zero-cost exceptions. It's the one case I can think of where Rust forces a solution with a runtime cost compared to C++, even in unsafe code. It's also one of the few places where C++ offers higher-level abstractions than Rust. (I'd consider exceptions a higher-level abstraction than Results; of course, higher-level != better).
Arguments based on purity are borderline nonsensical since Rust is not a pure language, the type system isn't aware of side effects, and it's the only case where purity is prioritized over performance. I can respect the idea that errors are either nonserious and so should be handled in the normal control flow of the program, or serious enough to merit a full-blown panic, but I also lean towards the view that it's better to trust the programmer than remove tools from their toolbox.
5) Related to 4, I think Rust should've been designed with C++ binary compatibility as a first-class goal. Yes, this is very difficult, and would require compromising aspects of the language design. But it would be an enormous boon to Rust's adoption rate (and especially the goal of replacing unsafe code in the wild with safe code) if C++ projects could easily be incrementally rewritten in Rust, and it were possible for Rust to directly use C++ libraries and APIs.
---
(Yes, this list of issues is not internally consistent; the point is that addressing any of them in isolation would be an improvement).
> All the `.iter()` and `.iter_mut()` is verbose and could easily be inferred from context ... If it truly must be explicit — and allowing implicitness as an option doesn't preclude allowing explicitness as well — then introduce new method call operators to go along with the dot operator.
When you design your language based on feel on not based on principles that guide what should be defaulted to, you end up with a language that fits only very specific people. Designing based on principles allows people to learn the principles and then use intuition to guide them to in the direction of the correct feature or solution.
You pointed out the list is inconsistent. In my experience, when people have inconsistent feeling a about something that was designed with a consistent methodology, that's because they haven't yet grasped or accepted that methodology and are trying to shoehorn their ideas from other systems into it without recognizing there may already have been a very conscientious decision made about exactly those issues, and likely with more information to base the decision on.
> Rust should've been designed with C++ binary compatibility as a first-class goal. Yes, this is very difficult, and would require compromising aspects of the language design. But it would be an enormous boon to Rust's adoption rate
There are plenty of languages that sacrifice in the name of adoption. Too much and it's useful in the short term, but a losing proposition in the long term. Too little and you may never see enough adoption for it to matter (barring other sources of adoption).,
IIRC the reason not to detect overflow by default in release builds isn't any variant of "You Just Don't Get It", it's rather "yes we'd like to do that but unfortunately there is a trade-off with a significant runtime performance hit, so we don't, for now".
