3 ms·

Literally have never heard Rustaceans defend poor design choices like that before.

CalChris 10y ago
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.
- wahern 10y ago
  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.
- moosingin3space 10y ago
  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.
  - yoklov 10y ago
    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.
braveo 10y ago
You mean the way they defend some of the numerics in rust? yeah, totally have never seen that...
- moosingin3space 10y ago
  What in particular are you referring to? I ask honestly, because this "my way or the highway" attitude has never been the Rust community's way.
  - braveo 10y ago
    Their approach to overflow, for one.
    - moosingin3space 10y ago
      Last I checked, wrapping arithmetic and checked arithmetic are both supported. What is your complaint?
    - the_why_of_y 10y ago
      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".
      - braveo 10y ago
        You misunderstand me, I think it's folly to have different behaviors based upon debug and release builds. And they'll argue until they're blue in the face why it's a good "compromise", but it would have been better to do one or the other, not both.
smitherfield 10y ago
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).

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.

wahern 10y ago
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.
moosingin3space 10y ago
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.
- yoklov 10y ago
  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.

braveo 10y ago

You mean the way they defend some of the numerics in rust? yeah, totally have never seen that...

moosingin3space 10y ago
What in particular are you referring to? I ask honestly, because this "my way or the highway" attitude has never been the Rust community's way.
- braveo 10y ago
  Their approach to overflow, for one.
  - moosingin3space 10y ago
    Last I checked, wrapping arithmetic and checked arithmetic are both supported. What is your complaint?
  - the_why_of_y 10y ago
    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".
    - braveo 10y ago
      You misunderstand me, I think it's folly to have different behaviors based upon debug and release builds. And they'll argue until they're blue in the face why it's a good "compromise", but it would have been better to do one or the other, not both.

smitherfield 10y ago

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).