4 ms·

The Rust community is pretty good at turning specific complaints into actionable proposals. Could you perhaps be more specific about what nice things in Modula/

The Rust community is pretty good at turning specific complaints into actionable proposals. Could you perhaps be more specific about what nice things in Modula/Delphi/Eiffel are missing from other languages, or about what might be different if Go or Rust borrowed more of their influence?

Roboprog 10y ago
Thanks for the response, it was just a rant. I suspect the Rust community and I simply have irreconcilable differences. They want a better C or C++, and like special character ditties such as &, *, <_> (whatever that does), and I would rather have short keywords in some places. For example, declaring a parameter with "var" in a function heading means it is a reference, instead of a copy. However, there is no dereferencing syntax, you simply use it as if it were a local "auto"/stack type variable (which also cannot be a null, so no checks are required - which Rust probably takes care of as well if you ask nicely), and there is nothing special for the caller to do, unless the caller has a pointer that needs to be checked and then dereferenced in the call. I also miss reasonable "set" operations, even if the sets were just bit vectors on short enumerated types (enums or short sub-ranges of other discrete values). Maybe Rust has sane set operations, but Java's collections operations are a bit off: mutating "add-all" vs union producing a new set, and so on. Eiffel's pre/post-condition and class invariant special assertions are nice, as well.
- aweinstock 10y ago
  Rust's set types do implement the BitAnd and BitOr traits, which allow using the & operator for intersection, | for union (There's also a few others, like (Sub, -, set difference) and (BitXor, ^, symmetric difference)). They use Clone to construct a new set for the result, for use with a functional style. There are also the union/intersection methods that produce lazy iterators over references to the values in the sets, for cases where cloning the set elements would be too big a runtime price, at a slight cost to ergonomics. Clone-based operator overloading: https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.bitand https://doc.rust-lang.org/std/collections/struct.HashSet.htm... https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.bitor https://doc.rust-lang.org/std/collections/struct.HashSet.htm... Lazy-iterator-based methods: https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.intersection https://doc.rust-lang.org/std/collections/struct.HashSet.htm... https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.union https://doc.rust-lang.org/std/collections/struct.HashSet.htm... Do these qualify as reasonable set operations?
- steveklabnik 10y ago
  <_> is for when you want to specify the outer type of a generic, but don't feel like explaining the inside. So if something could infer to a Vec<i32> or a Set<i32>, instead you can say Vec<_> and have it infer the inner type.

Roboprog 10y ago

Thanks for the response, it was just a rant. I suspect the Rust community and I simply have irreconcilable differences. They want a better C or C++, and like special character ditties such as &, *, <_> (whatever that does), and I would rather have short keywords in some places. For example, declaring a parameter with "var" in a function heading means it is a reference, instead of a copy. However, there is no dereferencing syntax, you simply use it as if it were a local "auto"/stack type variable (which also cannot be a null, so no checks are required - which Rust probably takes care of as well if you ask nicely), and there is nothing special for the caller to do, unless the caller has a pointer that needs to be checked and then dereferenced in the call. I also miss reasonable "set" operations, even if the sets were just bit vectors on short enumerated types (enums or short sub-ranges of other discrete values). Maybe Rust has sane set operations, but Java's collections operations are a bit off: mutating "add-all" vs union producing a new set, and so on. Eiffel's pre/post-condition and class invariant special assertions are nice, as well.

aweinstock 10y ago
Rust's set types do implement the BitAnd and BitOr traits, which allow using the & operator for intersection, | for union (There's also a few others, like (Sub, -, set difference) and (BitXor, ^, symmetric difference)). They use Clone to construct a new set for the result, for use with a functional style. There are also the union/intersection methods that produce lazy iterators over references to the values in the sets, for cases where cloning the set elements would be too big a runtime price, at a slight cost to ergonomics. Clone-based operator overloading: https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.bitand https://doc.rust-lang.org/std/collections/struct.HashSet.htm... https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.bitor https://doc.rust-lang.org/std/collections/struct.HashSet.htm... Lazy-iterator-based methods: https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.intersection https://doc.rust-lang.org/std/collections/struct.HashSet.htm... https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.union https://doc.rust-lang.org/std/collections/struct.HashSet.htm... Do these qualify as reasonable set operations?
steveklabnik 10y ago
<_> is for when you want to specify the outer type of a generic, but don't feel like explaining the inside. So if something could infer to a Vec<i32> or a Set<i32>, instead you can say Vec<_> and have it infer the inner type.