[staticassertion]

Honestly, who cares about not knowing that something was possible if you never wanted it? `dyn` working on the stack is more consistent than it not working on the stack.

I'd say one way to a language more completely is to:

a) Read its stackoverflow pages (not sure about Rust but this helped a ton with C++)

b) Get code reviews from others. The rust community is fairly active, or at least it was back when there was just an IRC channel, I don't know as much now since I don't get onto whatever the medium is today. Ask people if there's an easier way to do something.

c) Read others code. I, for example, like to review some of my dependencies just so I understand a bit more about how they work, and I've picked up a lot from that. I used to get on IRC in the morning while I was kinda getting into my work-day and see if I couldn't help others out, this really taught me a lot.

[brundolf]

> who cares about not knowing that something was possible if you never wanted it?

I have wanted that feature at times in the past (or something like it), and wasn't able to determine that it would be possible. That's exactly my point.

As for your suggestions: this is indeed one way to gather this knowledge, and I have learned a lot particularly from looking at stack overflow. But I don't think it's ideal when knowledge about fundamental language features has to be acquired by word-of-mouth, because it wasn't conveyed in the course of the normal learning path (official tutorials + discovery through application of learned concepts to new situations where their relevance is self-evident).

[staticassertion]

I guess when I assume a feature is possible, and I want to use that feature, I try it and see if it works.

I also don't typically learn via books myself, I learned rust pre-book, and basically entirely via IRC. To me, that's the default-path. But I get why it's not ideal - a written record (like the one linked) is definitely important to have, and it is a legitimate weakness that they're so nascent.