5 ms·

> - The type system is unusual, and complex. It's hard to do anything without templates. Do you mean the generic types and functions that stop you having to re

by dbaupp 10y ago

> - The type system is unusual, and complex. It's hard to do anything without templates. Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than <>'s in a few places. For one, not having generics would make it far more annoying to create reusable zero-cost abstractions around `unsafe` code, resulting in your other favourite criticism: more unsafe code for "unnecessary" (i.e. performance) reasons. > - The template libraries are heavily biased towards closure-oriented functional programming. This is cool, but hard to read. Parts of expressions are nameless and have no visible type. This is terse but hard to maintain. This isn't true: most generic types go via other schemes, and only use closures for simple combinators (making one line manipulations simpler and easier to read, but like with anything, can be abused), or when they're required to achieve the desired semantics (iterator pipelines). --- In any case, (some of) your proposed replacements don't make sense as the only built-in for their given functionality, for a systems language. If the task in question can take the loss of control, then Python (or similar) seems like a better choice for you. > would have gone for Python-type exceptions rather than error enums and macros, True Python-style exceptions require allocations to handle errors. > single-inheritance OOP rather than traits This forces dynamic dispatch everywhere and loses type safety (when passing types through functions and storing them in data structures), rather than being able to specialise functions and data types, and track exact types through code. Also, only offering single-inheritance has significant semantic problems, e.g. what happens when your type is both equatable and cloneable? > Python-type with clauses rather than RAII What exactly does this address? It seems just like a syntactic rephrasing of `let x = foo()`, given it would have to be compulsory for certain types, or else guarantees are lost. --- Rust is, as you say, different to other languages, but very little of it (and none of the features you call out) was chosen just to be gratuitously different. The new features of course might just take a little time to get used to if one is coming from mainstream imperative/OOP languages.

sidlls 10y ago
Rust's generics have significant limitations, especially when mixing types, and are cumbersome to use. For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting that require non-trivial workarounds (it is ridiculous, frankly, that the num crate isn't in the standard library, but that crate has its own problems). And there is no specialization, which is a severe limitation. Can't disagree with your comments re: python.
- pcwalton 10y ago
  > The way the Rust compiler works it isn't possible without specifying various bounds on the traits. That's a feature! It works the same way in every language other than C++ or D that implements generics. I much prefer explicitly typed generics to untyped generics as in C++. Not only are the error messages far more comprehensible, but it lets us avoid having to introduce confusing name resolution rules like ADL. > And there is no specialization, which is a severe limitation. There is now [1]. [1]: https://github.com/rust-lang/rust/pull/30652 https://github.com/rust-lang/rust/pull/30652
  - sidlls 10y ago
    Well "the same way" is pretty broad. Generics in C++ are too loose and I edited my comment to reflect that I appreciate the explicitness required. That doesn't mean it couldn't be revisited for usability. Also, huzzah for specialization. I'll try that out asap. Thanks for the heads up.
    - pjmlp 10y ago
      Not for much longer I hope, and we already have concepts in gcc 6.0. Just wait for C++20 and STLv2, you will also get that explicitness everywhere with concepts.
- dbaupp 10y ago
  This isn't wrong, but it seems to be putting the cart before the horse: even with limitations, having generics is still an improvement over not having them, in terms of one's ability to build type-safe abstractions (i.e. Rust would be a far weaker language without them). For instance, one can write a complicated lock-free data structure that works with any type T, doing the effort to optimise the atomic orderings and avoid leaks (etc.), all without forcing dynamic type casts or unnecessary allocations on downstream users. > The way the Rust compiler works it isn't possible without specifying various bounds on the traits. This is an explicit choice: C++-style check-at-use-site results in some seriously ridiculous error messages, and there's no boundary between implementation and signature, meaning a change to some small detail (and even syntax, in C++) in the implementation can accidentally cause downstream code to fail to compile. It is definitely annoying some times, but Rust, and most other languages with some sort of templates/generics, thinks the benefits outweigh the cost. > And there is no specialization, which is a severe limitation. Indeed, it is a limitation that the team recognises and is working on: https://github.com/rust-lang/rust/issues/31844 https://github.com/rust-lang/rust/issues/31844 (Parts of which are already available in the nightly releases.)

by dbaupp 10y ago

sidlls 10y ago

Rust's generics have significant limitations, especially when mixing types, and are cumbersome to use. For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting that require non-trivial workarounds (it is ridiculous, frankly, that the num crate isn't in the standard library, but that crate has its own problems). And there is no specialization, which is a severe limitation. Can't disagree with your comments re: python.

pcwalton 10y ago
> The way the Rust compiler works it isn't possible without specifying various bounds on the traits. That's a feature! It works the same way in every language other than C++ or D that implements generics. I much prefer explicitly typed generics to untyped generics as in C++. Not only are the error messages far more comprehensible, but it lets us avoid having to introduce confusing name resolution rules like ADL. > And there is no specialization, which is a severe limitation. There is now [1]. [1]: https://github.com/rust-lang/rust/pull/30652 https://github.com/rust-lang/rust/pull/30652
- sidlls 10y ago
  Well "the same way" is pretty broad. Generics in C++ are too loose and I edited my comment to reflect that I appreciate the explicitness required. That doesn't mean it couldn't be revisited for usability. Also, huzzah for specialization. I'll try that out asap. Thanks for the heads up.
  - pjmlp 10y ago
    Not for much longer I hope, and we already have concepts in gcc 6.0. Just wait for C++20 and STLv2, you will also get that explicitness everywhere with concepts.
dbaupp 10y ago
This isn't wrong, but it seems to be putting the cart before the horse: even with limitations, having generics is still an improvement over not having them, in terms of one's ability to build type-safe abstractions (i.e. Rust would be a far weaker language without them). For instance, one can write a complicated lock-free data structure that works with any type T, doing the effort to optimise the atomic orderings and avoid leaks (etc.), all without forcing dynamic type casts or unnecessary allocations on downstream users. > The way the Rust compiler works it isn't possible without specifying various bounds on the traits. This is an explicit choice: C++-style check-at-use-site results in some seriously ridiculous error messages, and there's no boundary between implementation and signature, meaning a change to some small detail (and even syntax, in C++) in the implementation can accidentally cause downstream code to fail to compile. It is definitely annoying some times, but Rust, and most other languages with some sort of templates/generics, thinks the benefits outweigh the cost. > And there is no specialization, which is a severe limitation. Indeed, it is a limitation that the team recognises and is working on: https://github.com/rust-lang/rust/issues/31844 https://github.com/rust-lang/rust/issues/31844 (Parts of which are already available in the nightly releases.)