4 ms·

I have read The Rust Programming Language from start to beginning and afterwards decided to use Go instead because Rust does not have a Garbage Collector. If so

I have read The Rust Programming Language from start to beginning and afterwards decided to use Go instead because Rust does not have a Garbage Collector. If somebody added a GC to it, including syntactic sugar that doesn't make it feel 'glued on', then I'd be happy to use it. Something else ultimately turned me away from investing more time into it, though: Chapter 17 of the book, which spends a great deal of time trying to advertise why its OOP support is so impoverished. In comparison, Donovan & Kernighan's The Go Programming Language is much more honest about the (many) misfeatures of Go. That being said, already existing libraries and Rust's tooling are excellent, and so I'll surely return to the language. Not because it has no optional GC but despite of it.

steveklabnik 8y ago
What did you find dishonest? Chapter 17 was one of the hardest to write.
- jonathanstrange 8y ago
  First of all, I didn't use the word "dishonest", there is nothing dishonest about your book. It is a fine book. :) What I found problematic was the section on "Inheritance as a Type System and as Code Sharing", especially the paragraph "Inheritance has recently fallen out of favor..." While there is some truth to the claim, you forget to mention that there are also metric tons of highly successful OOP based software libraries out there, that it is perfectly feasible to use inheritance (and multiple inheritance) in good and productive ways, and that the Rust community is still quibbling about how to implement GUI frameworks in a "Rust way" and how to interface to foreign OOP libraries in general because of Rust's OOP limitations. It is a drawback not to have full OOP with inheritance and multiple dynamic dispatch. A non-biased and informed language user may choose Rust despite this limitation, but not because of it. Another thing I found problematic was the "newtype pattern" pp. 439-441. Whether the wrapper is optimized away or not, the newtype pattern is clearly a cumbersome solution for a language limitation. At least to a beginner who has seen many other languages, this just looks like a horrible workaround for the lack of scalar subtypes, as e.g. Ada has them. To be honest, pp. 440-441 were probably the final reason why I decided to postpone writing software in Rust. (Coincidentally, Ada also allows you to define type aliases that are discussed on the following pages, but in Ada they are normally considered bad style and only used for clearly identifiable abbreviations.) That being said, I found your book very informative and overall good reading, and I'm planning to come back to Rust once I have the time.
  - steveklabnik 8y ago
    That's true, but you did say that the other book is "more honest", which to me implies dishonesty. No worries regardless. > A non-biased and informed language user may choose Rust despite this limitation, but not because of it. Yeah, I guess this comes down to a difference in perspective; many people do prefer that Rust has no inheritance, and if it did, would choose Rust despite that, not because of it :) > the newtype pattern is clearly a cumbersome solution for a language limitation. It depends on your view too; that is, sub-typing has a lot of other problems. Sometimes, this "cumbersome"ness is what you want, because you don't want everything automatically forwarded through. For situations where you do, there has been talk of adding delegation support in some fashion. Anyway, thank you, this is all good to know :)
  - pcwalton 8y ago
    Rust would be a worse language if it had traditional OO support. I sort of proposed such a thing at one point and we ended up backing it out. Newtypes are better for Rust's purposes than subtypes because they interact better with type inference, which is deeply important, especially when trait matching is concerned. Subtyping makes type inference much more complicated, and in fact a long-term goal in rustc is to remove all subtyping from the typechecker and relegate it to the lifetime pass.
    - 13415 8y ago
      I don't buy this, things like that are not a matter of "perspective". 1. A language that has an optional GC and a borrow-checker is better than a language that only has a GC or borrow-checker. 2. A language that has scalar subtypes with range checking and new types is better than a language that has only new types and no range checking. So subtyping is complicated to implement in the typechecker. And? If GNAT can do it, why can't the Rust team not do it? 3. A language that has full support for OOP including inheritance and traits (or mixins) is better than a language that has less of these features. I'm not claiming that every language should offer everything but a general purpose language that wants to be a viable substitute for C++ should at least have its OO capabilities.
pcwalton 8y ago
Rust will never have a garbage collector in the sense that other languages do. It just would not interoperate well with ownership and borrowing.

steveklabnik 8y ago

What did you find dishonest? Chapter 17 was one of the hardest to write.

jonathanstrange 8y ago
First of all, I didn't use the word "dishonest", there is nothing dishonest about your book. It is a fine book. :) What I found problematic was the section on "Inheritance as a Type System and as Code Sharing", especially the paragraph "Inheritance has recently fallen out of favor..." While there is some truth to the claim, you forget to mention that there are also metric tons of highly successful OOP based software libraries out there, that it is perfectly feasible to use inheritance (and multiple inheritance) in good and productive ways, and that the Rust community is still quibbling about how to implement GUI frameworks in a "Rust way" and how to interface to foreign OOP libraries in general because of Rust's OOP limitations. It is a drawback not to have full OOP with inheritance and multiple dynamic dispatch. A non-biased and informed language user may choose Rust despite this limitation, but not because of it. Another thing I found problematic was the "newtype pattern" pp. 439-441. Whether the wrapper is optimized away or not, the newtype pattern is clearly a cumbersome solution for a language limitation. At least to a beginner who has seen many other languages, this just looks like a horrible workaround for the lack of scalar subtypes, as e.g. Ada has them. To be honest, pp. 440-441 were probably the final reason why I decided to postpone writing software in Rust. (Coincidentally, Ada also allows you to define type aliases that are discussed on the following pages, but in Ada they are normally considered bad style and only used for clearly identifiable abbreviations.) That being said, I found your book very informative and overall good reading, and I'm planning to come back to Rust once I have the time.
- steveklabnik 8y ago
  That's true, but you did say that the other book is "more honest", which to me implies dishonesty. No worries regardless. > A non-biased and informed language user may choose Rust despite this limitation, but not because of it. Yeah, I guess this comes down to a difference in perspective; many people do prefer that Rust has no inheritance, and if it did, would choose Rust despite that, not because of it :) > the newtype pattern is clearly a cumbersome solution for a language limitation. It depends on your view too; that is, sub-typing has a lot of other problems. Sometimes, this "cumbersome"ness is what you want, because you don't want everything automatically forwarded through. For situations where you do, there has been talk of adding delegation support in some fashion. Anyway, thank you, this is all good to know :)
- pcwalton 8y ago
  Rust would be a worse language if it had traditional OO support. I sort of proposed such a thing at one point and we ended up backing it out. Newtypes are better for Rust's purposes than subtypes because they interact better with type inference, which is deeply important, especially when trait matching is concerned. Subtyping makes type inference much more complicated, and in fact a long-term goal in rustc is to remove all subtyping from the typechecker and relegate it to the lifetime pass.
  - 13415 8y ago
    I don't buy this, things like that are not a matter of "perspective". 1. A language that has an optional GC and a borrow-checker is better than a language that only has a GC or borrow-checker. 2. A language that has scalar subtypes with range checking and new types is better than a language that has only new types and no range checking. So subtyping is complicated to implement in the typechecker. And? If GNAT can do it, why can't the Rust team not do it? 3. A language that has full support for OOP including inheritance and traits (or mixins) is better than a language that has less of these features. I'm not claiming that every language should offer everything but a general purpose language that wants to be a viable substitute for C++ should at least have its OO capabilities.

pcwalton 8y ago

Rust will never have a garbage collector in the sense that other languages do. It just would not interoperate well with ownership and borrowing.