[Rust] Extract Concepts from v2 exercise parallel-letter-frequency

[lewisclement]

Initial list with concept level abstraction of common elements used for solving parallel-letter-frequency.

Something I'm not entirely certain about is the separation of "Tuples" and "Destructuring". But since destructuring can also be applied to structs (and soon for slices will also be in stable) I placed it as it's own concept.

[coriolinus]

@SleeplessByte One of the concepts we're likely to include for Rust is parallelism. If I were to attempt to design a parallelism concept exercise from scratch, I suspect I might end up something very like parallel-letter-frequency.

How would you go about designing a narrower concept exercise for parallelism?

[SleeplessByte]

@coriolinus that's a good question and I had to think about it for a minute. Most likely I would not have picked parallism as the concept for the exercise, but have two exercises, or have two funtions where one explores channels and one explores arcs.

I would probably have an interface that returns a channel which woud require the student to compose it (learning the methods on channels) before having to create their own. Or I would check the return type or whatever. I would give students more to start with and box them in more, from a boundary standpoint.

For example, in JavaScript there is no way to force someone to write async/await over Promise, because it's just syntactic sugar. However sometimes the former produces vastly easier code than the latter (ánd vice versa). That, together with a stub, docs, instructions and hints that all point to one over the other, basically makes it so that people should only solve it one way.

---

re this exercise: I think it's super interesting, but for example it has flaws. You can solve this exercise by always assuming a worker count of 1, and not doing anything in parallel. If I recall correctly.

[lewisclement]

For example, in JavaScript there is no way to force someone to write async/await over Promise, because it's just syntactic sugar. However sometimes the former produces vastly easier code than the latter (ánd vice versa). That, together with a stub, docs, instructions and hints that all point to one over the other, basically makes it so that people should only solve it one way.

Agreed. Luckily with certain specific concepts like reference counting and channels we indeed have a way to test a specific approach, like you suggested. Would you say that those specific approaches (like mutexes/Arc's/channels/promises) should be considered their own concepts?

[SleeplessByte]

In my opinion, and I'm no real authority here, yes. Absolutely!

A mutex in computer science is its own concept compared to say... a "monitor"/"regular lock". Channels imo (streams++) are also something different than a future (promise). All have to do with concurrency and/or parallelism (not necessarily both), but they can be their own concepts.

I personally would love to learn about each of these in Rust, given that I'm such a novice, but I know how to do these in Kotlin, JavaScript, Ruby and C#, and in those four languages they are also vastly different approaches, and thus concepts.

[lewisclement]

That way we'll get to those 30 exercises quite easily. I will also have to extend the current list with some examples of these other approaches. Definitely more advanced material though.

@coriolinus and/or @filalex77 , what's your take on this?

[SleeplessByte]

When we were discussing concept exercises and the number we would need, that's something that came up as well. It's very likely that you'll have a concept exercise teaching "strings-basic", but others that deal with for example en-or-transcoding. Or parsing. Or formatting. Or whatever a language has in features.

Then, in practice exercises (think old v2 exercises), you get to bring all these concepts together and practise on using them in more comprehensive, larger exercises, that are mentored.

---

Edit: here is a good read from some authority: https://exercism-team.slack.com/archives/CC5DGSAG6/p1579722161067300

[kotp]

This appears to include much more than what the title suggests. Is this branch rebased on master?

[lewisclement]

This appears to include much more than what the title suggests. Is this branch rebased on master?

Trying to. Currently receiving help from @iHiD on Slack.

[Br1ght0ne]

I find this list very detailed and complete in the context of this exercise. I especially appreciate the focus on std-centric implementations.