3 ms·

> One of the things I like most about Rust is that it forces you to think through your design and address complex tradeoffs, and often won't even compile until

> One of the things I like most about Rust is that it forces you to think through your design and address complex tradeoffs, and often won't even compile until you do. I have heard this bullshit enough times. "Orange crab god doesn't like it so you are doing it wrong". No, you shouldn't have to care about memory management nuisances when that's not relevant and rust being a language suited for systems domains with correct static memory management (Good thing for systems domain), makes those irrelevant details surface in implementation.. what you said isn't true for other domains. This kind of shilling is what leads to rust evangelism strike force memes.

fluffything 6y ago
I don't think they are talking about memory management here, but simple API design. In C++ you can write: template <typename Animal> void roar(Animal animal) { ... } and call it like this: roar(airplane); // How do Airplanes roar? You can try to fix that with an "Animal" concept, but it turns out that if someone adds a roar method to a Vehicle, you can still: roar(truck); // Trucks can roar... but roar expected Animal In Rust, these things just cannot happen. If you write: fn roar(animal: impl Animal); then trying to call it with anything that's not an animal will fail to compile. That's a good thing, but maybe somebody did wanted to call roar with a truck, and now you have to invest time into more precisely thinking which types should roar actually take, which types constraints make sense defining, how you categorize types, etc. In Rust thinking about these things costs time. In C++ it also costs time, usually more than Rust, because you have to go way out of your way to prevent mistakes like the above. In Go you don't have to think about these issues at all because the language does not allow you to do most of this (except for interfaces, but that's another story).
- entha_saava 6y ago
  I should first tell that I don't hate rust. It is a well designed language for what it aims for (statically guaranteed memory safety for systems programming). I have deep respect for rust creator and some members of core team for their technical work. What irritates me is claims like "If borrow checker rejects your code, it was wrongly structured anyway" and "rust's restrictions lead to good structured code". It is not wrong if program logic requires self referential structures, for example. Neither does it make sense to evangelize rust using blanket statements like this. I get the impression that some people are trying to evangelize rust as a language for everything. The mental overhead of rust (or maybe ATS, maybe Ada/SPARK, depending on requirements) makes sense for systems programming, where C/C++ will make stuff even more complicated, and you can't compromise on performance. The applications domain is realistically better served by something like F# / OCaml / Go once it gets generics..
  - fluffything 6y ago
    > "If borrow checker rejects your code, it was wrongly structured anyway" Nobody is claiming that? At least not in this thread. I think your confusion stems for thinking that "Rust == borrow checker". The borrow checker is a tiny part of Rust. > The mental overhead of rust I find the mental overhead of Rust to be smaller than that of Python, Go, Java, Haskell, C, C++, Lisp, and pretty much any other language that I've ever used. In Rust I don't have to think about multi-threading, data-races, memory management, resource acquisition and release... the compiler does the thinking for me. I also can refactor and reshuffle code at will, and trust the compiler to catch all errors. Changing a type that pretty much every translation uses in a 500k LOC code base and add multi-threading to it? No problem, just try it out, and if it compiles, it is correct. I can't say the same of Go, Python, Java, etc. where threading errors are impossible to debug. And well, it wouldn't even be worth trying. It would be impossible to make sure that the code is correct, even after fuzzing for weeks.

fluffything 6y ago

I don't think they are talking about memory management here, but simple API design. In C++ you can write: template <typename Animal> void roar(Animal animal) { ... } and call it like this: roar(airplane); // How do Airplanes roar? You can try to fix that with an "Animal" concept, but it turns out that if someone adds a roar method to a Vehicle, you can still: roar(truck); // Trucks can roar... but roar expected Animal In Rust, these things just cannot happen. If you write: fn roar(animal: impl Animal); then trying to call it with anything that's not an animal will fail to compile. That's a good thing, but maybe somebody did wanted to call roar with a truck, and now you have to invest time into more precisely thinking which types should roar actually take, which types constraints make sense defining, how you categorize types, etc. In Rust thinking about these things costs time. In C++ it also costs time, usually more than Rust, because you have to go way out of your way to prevent mistakes like the above. In Go you don't have to think about these issues at all because the language does not allow you to do most of this (except for interfaces, but that's another story).

entha_saava 6y ago
I should first tell that I don't hate rust. It is a well designed language for what it aims for (statically guaranteed memory safety for systems programming). I have deep respect for rust creator and some members of core team for their technical work. What irritates me is claims like "If borrow checker rejects your code, it was wrongly structured anyway" and "rust's restrictions lead to good structured code". It is not wrong if program logic requires self referential structures, for example. Neither does it make sense to evangelize rust using blanket statements like this. I get the impression that some people are trying to evangelize rust as a language for everything. The mental overhead of rust (or maybe ATS, maybe Ada/SPARK, depending on requirements) makes sense for systems programming, where C/C++ will make stuff even more complicated, and you can't compromise on performance. The applications domain is realistically better served by something like F# / OCaml / Go once it gets generics..
- fluffything 6y ago
  > "If borrow checker rejects your code, it was wrongly structured anyway" Nobody is claiming that? At least not in this thread. I think your confusion stems for thinking that "Rust == borrow checker". The borrow checker is a tiny part of Rust. > The mental overhead of rust I find the mental overhead of Rust to be smaller than that of Python, Go, Java, Haskell, C, C++, Lisp, and pretty much any other language that I've ever used. In Rust I don't have to think about multi-threading, data-races, memory management, resource acquisition and release... the compiler does the thinking for me. I also can refactor and reshuffle code at will, and trust the compiler to catch all errors. Changing a type that pretty much every translation uses in a 500k LOC code base and add multi-threading to it? No problem, just try it out, and if it compiles, it is correct. I can't say the same of Go, Python, Java, etc. where threading errors are impossible to debug. And well, it wouldn't even be worth trying. It would be impossible to make sure that the code is correct, even after fuzzing for weeks.