What I find quite useful is to re-read the whole Chapter 10 (Type System) of the Rust reference.
But I wonder if there's somewhere a more tabular overview, maybe with references to other programming languages like Haskell, which also might answer questions such as, "is there such a thing as HRTBs in Haskell?", or languages like Java, C(++), etc.
Even if (stable) Rust doesn't provide all the constructs listed above, it may be helpful to know and understand them to be able to understand the limitations of Rust's type system (and how to work around them).
I feel like much of Rust's complexity is owed to the complexity of type systems in general, so maybe providing a good overview on these topics might help to get more people into Rust more easily (and ideally save them from the some headaches I had)…
In my experience, learning type theory in general was indeed useful for internalizing concepts from Rust's type system. The type system of the language is pretty close to other, mainstream statically-typed functional languages (with the notable exception of ownership and borrowing, which is not something most languages provide type support for).
So I think writing a general introduction to classic functional type systems could be a fruitful addition to existing guides.
I don't know, but when people start talking about types in a rather abstract way, I tend to switch off. I tend to think about Rust more in terms of computer memory and pointers, and the compiler checking that memory is properly initialised, and pointers are valid. I think "the book" does an excellent job of explaining Rust types and lifetimes, although it's not entirely comprehensive. Perhaps it would help people with different backgrounds to myself though. Mostly I think writing lots of code is the way to learn, for me at any rate.
Having in-depth explanation about the type system would be really nice, but I'm afraid that recommending it to beginners might introduce the Monad problem to the Rust.
When programmers attempt to learn Haskell, usually they face the hello world tutorial mentioning the terminology "Monad". Probably it's first time to see this word for them so they google it, which leads them to load of monad tutorials about the type theory. Many of them quit here. But the survived few tends to become enthusiastic which make the problem worse. But really, you don't need to know what monad is to write a practical Haskell program.
Starting with the fact that of the 20 odd points you listed there most of them meant nothing to me when coming to Rust. Despite having programmed in a bunch of different languages over many years they were words and acronyms I had never heard of.
Still after a year or so a good percentage on the list does not ring any bells.
That before we even get to the "m" word.
Typically my programming experience has been about moving data around and crushing on it. Concrete data like int's, floats, strings and structs containing them. It was all about data and control flow. Think C for example.
With Rust it feels like one has to spend most of ones effort thinking about the type system rather than what I want the program to actually do.
I'm not complaining. I'm pretty sure this is just a matter of my missing out on an education in CS and any exposure to functional programming. I'm trusting that the smart folks building Rust have done all this for my own good and I just have to get my head around it all.
In the mean time, I mostly write Rust as if it were C. As far as the compiler will let me
I think the tricky (and amazing) thing about Rust is that it both has a very advanced type system and operates quite low-level and memory optimized. While the last makes experiences with C, pointers, and such helpful; the first makes knowledge about type systems helpful.
It's understandable when things get mathematically abstract, and I also had moments where I "switched off". However, I do believe that sometimes things appear more complex than they really are – unless explained properly. I think the less people are confused when hitting complex types or bounds, the less people will get frustrated with Rust (but that's just my hypothesis for now).
I agree. Different people likely prefer different approaches to the language. I tend to "need" an overview in order to feel comfortable. With Rust, it sometimes felt like being impossible to gain such an overview. That's what made it (at times) frustrating (but then also so much more rewarding when I finally understood some things.)
I think bringing the Monad example from Haskell to the Rust world, that would be like teaching beginners about the (yet experimental) Residual. Taking a look at my list above, you'll see I didn't even include particular type(-constructor)s or traits like Iterators, slices, the Result type, or Option in the list.
Instead, my proposal is to look closer at the foundations of the type system, not at concrete types (with a few exceptions as the "never type" maybe).
But do you need to know what a Result is, in order to write a practical Rust program? I would say: Yes. But again, that's not what I was originally talking about, as I didn't bring up particular types or traits from the standard library. Instead, I'd like to state the hypothesis that understanding (or at least feeling) the difference between types, traits, type constructors, trait objects, type parameters, associatated types, etc. will be helpful (or even needed) at some point. And it's difficult to get an overview on all of these.
I don't want to imply people should start with HRTBs, but I sometimes feel like the type system in Rust is often taught in tiny chunks and my personal experience was that I missed some good review of the type system as a whole. That, in turn, made me feel like Rust has an infinite complexity, and I'd stumble over and over about new concepts that make me wonder if I understood Rust in the first place.
But perhaps that's just my own perception and other people feel happier with learning by example and don't need an overview. In fact, I also went through Rust By Example, and it did help me.
I don't find these points that odd . I knew some of these concepts from playing with Haskell. That said, I don't think it should be necessary to learn Haskell in order to get a good understanding about Rust – assuming these concepts are explained properly somewhere (ideally related to practical usage in Rust!).
Meanwhile I have at least an idea of each of the things listed in my original list above. I just added two more points to the list (see edit above):
generalized algebraic data types (GADTs) (though I think these don't exist in Rust)
const generics
Learning functional programming was an interesting experience. It almost felt like I had to re-learn programming from the beginning. Rust doesn't feel very functional to me, even if it certainly has some functional peculiarities (but I'm not an expert on programming languages in theory). I think what a complex type system can achieve is:
catching more errors at compile-time rather than run-time,
allowing creation of abstract interfaces which can make code be re-used more easily.
Unfortunately, when you want to use a strict type system to declare abstract interfaces, things quickly get complex. AFAIK, it's still not possible (or at least difficult?) to express something like a Functor. Likewise, in a couple of real-life problems, I encountered limitations of the type system of "stable" Rust. One example is when you try to implement async trait methods in an efficient way.
I really love to use traits, which aren't available in C. And this often takes me to the rough edges of Rust, where things feel a bit unfinished yet (at least when using async).
I have spent far too many hours, days, even weeks, hunting down catastrophic failures in embedded system. Often under great pressure because those systems were already shipped and installed, down time means penalty payments. Often involving unfamiliar code written by disbanded teams. Often ending up being caused by some memory leak, pointer misuse or thread unsafely.
I wish there had been a Rust, with all its correctness assurances, at the start of my career rather than near the end!
I think what I would have liked on discovering Rust is an introduction targeted at old school C programmers who don't understand even the language in which Rust is described never mind Rust itself. Those terms naming and describing many features of Rust need spelling out along with some offering some indication of why they even exist and why I would want/need them.
As others have said, approaching Rust can make one feel that one knows nothing of programming and is starting over from scratch. I imagine it's like what happened when introducing structured programming in a high level language to a world of long time assembler programmers. Back in the day those guys resisted the idea pretty strongly.
. I knew some of these concepts from playing with Haskell. That said, I don't think it should be necessary to learn Haskell in order to get a good understanding about Rust – assuming these concepts are explained properly somewhere (ideally related to practical usage in Rust!).