[Rust] String-vs-str concept exercise

[gilescope]

Creating well escaped csv files is something every developer should strive for so I think this is a helpful exercise!
Also demostrates consumption of an owned value. (Fixes #1095 )

[gilescope]

It's says: "Forgot to run Prettier?" - is there a tool I should be running to check the .md files conform?

[coriolinus]

/format

[github-actions]

For security reasons, /format does not trigger CI builds when the PR has been submitted from a fork. To make the required checks pass, you need to trigger a build through one of the following ways:

• Push an empty commit to this branch: git commit --allow-empty -m "Trigger builds".
• Close and reopen the PR.
• Push a regular commit to this branch.

[coriolinus]

Lots of small fixes. Overall seems positive. We might want to copy or move substantial documentation from instructions.md into introduction.md, the String concept, or some other relevant place. I'm not entirely up-to-date on the project layout.

Items marked "nit" are matters of opinion; if you disagree, feel free to just say so and mark them resolved.

[ghost]

Thanks for contributing @gilescope! I love the CSV idea. That is something I have to work with frequently so find this a grand combination of Rust and a practical problem.

It's says: "Forgot to run Prettier?" - is there a tool I should be running to check the .md files conform?

Pro tip: you can run the formatting script locally if you want with EXERCISM_PRETTIER_VERSION=2.1.2 ./bin/format.sh. It runs it on everything in the repository.

[gilescope]

Ok updated version.

There's no slicing done at all. I think that's fine and lives in a more &str focused exercise. - maybe something parsing related? (A get out of this without allocating exercise... -- hmm makes me wonder if we can have some exercises that are no_std so that we can teach &str without there being the possibiliity of allocating... yes there's some fun potentially to be had there.)

[coriolinus]

Thanks for all the work @gilescope!

As far as Rust goes, this is mergeable. However, I have not checked against the v3 format or style guide. In particular, I think there should be some kind of json file declaraing the prerequisites, concepts unlocked, etc. I believe @ErikSchierboom is the subject expert there.

[gilescope]

Cool - I am sure more things will come to me once I see it in situ on the site. I'm sure we will revisit as I know more about the process.

[ErikSchierboom]

This is great work! I've left some comments. Feel free to ask any questions if you have them. Some general comments on this PR that don't apply to a single file:

• The exercise is currently named string-vs-str. We switched to having exercise being named after their story/theme (see this document) a while back. Could you rename the exercise and update its directory name accordingly?

• There are some missing files. As @coriolinus mentioned, each track has a config.json file that contains the track's metadata. This metadata includes the Concept Exercises and the Concepts. Could you add metadata for this Concept Exercises and its concept(s) to Rust's config.json file?

The concept-specific files are missing. See the spec for more information.

I've approved this PR so you can decide to either merge it now and do follow-up PRs to address the comments, or keep this PR open and address the comments in this PR. Whatever you prefer! Great job!

[ErikSchierboom]

General hints are listed in a ## General section:

Suggested change

	# General references on rust strings:
	## General

See the spec for more information.

[ErikSchierboom]

Are these articles directly related to helping unblock the student? The heading seems to imply that they are not so. If they are indeed not needed by the student, I'd remove them here. We do have a good location though for these links, and that is in the concept's links.json file: see the spec. In short, each concept taught by a Concept Exercise has its own documents, including a links.json for linking to interesting resources, which these links are perfect for.

[ErikSchierboom]

Two types of hints are allowed in a hints.md file:

1. General hints under a ## General heading
2. Task-specific hints under a heading that matches the task title in the instructions.md file (e.g. ## 2. Do Y)

This hints file does not have any task-specific hints, which in general are preferred over general hints due to task specific hints potentially "unblocking" students better. We didn't have this in our docs, so I've added just it: exercism/docs#19

Are there perhaps task-specific hints that you can think of? Here is a C# example: https://github.com/exercism/v3/blob/master/languages/csharp/exercises/concept/log-levels/.docs/hints.md

[ErikSchierboom]

While the RFC is a well-defined formal specification, there are two issues with it:

1. It requires the student to read an external resource, which is not ideal as it requires switching between an external resource and the instructions.
2. The specification itself, while precise, can be hard to read for people. Not all students will be experienced programmers.

What I would recommend is to extract the relevant parts from the RFC and explicitly list them in this document.

[ErikSchierboom]

The instructions have a very clear domain: building CSV records. For Concept Exercises, we strive to have instructions be a bit like a story. The reason for that is that we've found that having some sort of theme/story in an exercise makes students more involved in the exercise.

The story itself can be somewhat more elaborate (like this example), or just one line (like this example). Most exercises tend towards the smaller, more concise stories, which can be easier to process for students. Whichever you prefer :)

I'm more than happy to merge this as is, if you'd like to add a story/theme later.

[ErikSchierboom]

See above comment.

[ErikSchierboom]

This file is well-written! It is slightly on the longer side though. As per the spec:

The information provided should give the student just enough context to figure out the solution themselves.

What this means is that this file contain just enough information for the student to figure things out by themselves. There are often aspects of a concept that are very interesting, but that the student does not need to understand in order to solve the exercise. This type of information should be removed from the introduction.md file. There is another place to put this information though, which is the concept's about.md file (see the spec). This file is shown once the student finishes the exercise, and can go in far more detail on a concept than the introduction.md allows for.

I'll leave it up to you to decide what is essential for the student :) A good way to go about this would be to check the example solution, as that should be solution you expect the student to write.

[ErikSchierboom]

What does the invalid do? Never seen that used before, interesting!

[coriolinus]

The only place I'm really familiar with seeing multiple tags on a code fence like that is when writing Rust documentation; tagging a snippet as "invalid" will render it with a red box surrounding it and a popup noting that this is invalid. It also won't attempt to compile it as a doctest.

That said, I did check; the GFM renderer appears to properly render the sample as Rust, which is sufficient.

[ErikSchierboom]

Thanks for the explanation!

[ErikSchierboom]

(In Java or C#, this type is called StringBuilder.)

This bit will only really be useful to Java or C# programmers, which means that it won't benefit students not familiar with those languages. It can be very useful information, so you could:

1. Leave it as is
2. Rewrite it slightly, to something like: In some languages, this type is referred to as a `StringBuilder`.

Whatever you prefer :)

[ErikSchierboom]

As per the spec:

Links should be used sparingly, if at all. While a link explaining a complex topic like recursion might be useful, for most concepts the links will provide more information than needed so explaining things concisely inline should be the aim.

This section sounds very interesting, but it looks like the student does not need to know this to solve the exercise. This is perfect for the concept's about.md file though.

[ghost]

Looks great! 🎉 I say we cover the further feedback in a separate PR.
I will merge this now 😄