Hi! As discussed on Discord, I would like to become maintainer of the Rust track. I definitely have enough time to dedicate to this regularly and I’m open to receive input as to how I should go about doing it.
My instinct is telling me it would be best to start small, go over open issues, cleanup, respond to minor feedback. I know there are open issues on GitHub and threads on this forum that have never been responded to.
As an intermediary goal, I’d like to try using the official linter clippy to provide automated feedback for all exercises. Right now, I think there is only some ad-hoc feedback generated for very specific exercises. From my mentoring experience, I know that many users don’t use clippy themselves and the feedback it provides is very educational.
That sounds great! You could also consider adding exercises if you’d like that. @dem4ron has added a script to greatly help with this (it’s in the bin directory).
@senekor Thank you. The thing we’d really love to do is get the syllabus sorted. That’s the main priority in my mind. As Erik says, Aron’s generator is adding lots of Practice Exercises so that should enrich the track - but getting the syllabus sorted is where we really need your energy.
To get it live, we really need some more (~10?) exercises on fundamental programming things (so like strings, numbers, conditionals, etc) rather than on Rust-specific topics. The easiest way to achieve this is to copy over Learning Exercises from other tracks and making Rust-specific.
Would you be up for having a call with Erik where you can plan things out? I think it would increase the likelihood of this going well lots!
I don’t think this is enough. The reported difficulties were with Rust-specific features. See Feeling lost and frustrated in Rust for pointers to relevant & missing concepts and suggestions. I estimate that, if you are not familiar with Rust, it is easy to underestimate these features’ importance. Beware.
@senekor Feel free to call on me for reviews / thoughts.
Yeah, I think all of these things are important too.
But also the key to a good syllabus is covering fundamentals one at a time. The big problem in syllabuses is when the difficulty jump is huge. The issue is feeling lost and frustrated, and that happens when you’re required to write something in a language that you’ve not had explained. By firstly teaching concepts that people are familiar with you’re getting them comfortable with transfering their existing mental model to Rust, with dealing with the compiler, etc. And then as soon as you need to teach a Rust concept to move someone forward, we can do that.
If, of course, you need to teach a Rust-specific concept to do a basic thing (such as write if/else) then that’s a great time to also introduce that Concept in that exercise.
The main reason the Rust track hasn’t achieved a good syllabus is that trying to plan out something to teach all of Rust is too big and complex. Tracks that have created great syllabi have taken one small concept at a time and then discovered what extra knowledge you need to access it. Copying exercises from other tracks (if done in a thoughtful manner) tends to be a good way of quickly getting the scaffolding in place, and showing where the creation of totally bespoke exercises (a much more in depth-job) is needed.
So my TL;DR; is lets get some more exercises in using the path of least resistance, and then add more complex ones as we go.
Working on the syllabus would surely be a rewarding experience to me. The reason I didn’t suggest it is because:
I don’t have any experience writing exercises or working on a syllabus, so I would need help. Possibly from people working on the syllabus of other tracks.
I don’t think Rust is a language that can be learned (well) with a “Just start writing some code!” approach.
My naive idea for a Rust-syllabus would be to basically point people to the book and tell them: “Read this (sub-)chapter until you get it. Then come back and we’ll have a related concept exercise plus some practice exercises for you.”
The idea being that we need to communicate very clearly: “If you want to learn Rust, Exercism is not enough.” I think the thread referred to by @MatthijsBlom illustrates that well: Rust forces the programmer to be aware of and even master some fundamental comp sci concepts that other languages abstract away completely. People coming from those languages (which are probably most) need to learn all of that and I doubt the Exercism syllabus is the best place for that. Not all concepts are well suited to be taught in the context of a bite-sized coding exercise. Of course, the more original content we have to bridge the gap between theory and practice, the better.
That being said, I think a well-developed Rust syllabus could provide a lot of value to people learning Rust. Just reading the book - drowning oneself in theory without practice - is also not the best approach to learning. So my gut feeling is that our syllabus should try to complement the existing theoretical learning material that’s out there.
But again, I don’t have any actual experience working on a syllabus, so I’m open to having my mind changed / perspective expanded.
I’m happy to discuss the best way forward with Erik!
(@MatthijsBlom Thanks for the offer, I’ll keep it in mind! )
Also, the linked thread mentions there have been similar complaints in the past. Maybe a few pointers to those can be unearthed as well? The more I know about previous frustrations with the track, the higher the chance I can address them.
@ErikSchierboom I can generally make time for a call on most days, except Thursday, Friday and Sunday. I’m from Switzerland, so we’re in the same timezone I think.
(Prefix: My response here might sound defensive. I don’t mean it to do, but I’ve years of frustration with people wanting to take non-standard approaches to building tracks and them failing, whereas when people follow the roadmap we’ve spent years evolving, they work really well. And I don’t want to see lots of wasted effort and eventual frustration again in Rust! So please read any emotion in this post as passion, not annoyance )
Thanks for the replies!
There’s two areas here that I fundamentally disagree with.
1. That the Exercism approach to learning is “just start writing some code”.
For the first, it’s important to understand that tracks that have good syllabuses have put effort into explaining concepts very clearly. We don’t expect someone to just work stuff out - we explicitely go through and explain things. As a totally random example, look at the Elixir Anonymous functions introduction. This is what a student reads, and it’s the same sort of length and complexity as a “page” from the Rust book.
Now, in my mind, our job is therefore much easier as we can loosely just follow the Rust Book’s structure, split it up to be slightly more bitesized, use a lot of the actual text from the book, and point back to it for “read more here” where appropriate.
2. That Rust is so different from any other language that the learn-through-doing approach to coding doesn’t work.
Where tracks have seen themselves as “special” and approached this differently to how Exercism is designed, it’s just not worked. When tracks have followed the roadmap that we’ve spent years building, they work. The reason Rust has failed to materialise 4 times on 4 attempts is that so far no-one has just tried to follow the Exercism way of building a syllabus, which I am convinced would work absolutely fine for Rust just like it works for Go, Elixir, JQ, F# or any other language. I understand that Rust is complex and difficult to start with compared to other languages, but I fundamentally disagree that therefore it can’t be learnt by splitting into manageable chunks and reinforcing one’s constant knowledge acquisition by practicing those and building on them.
Of course, for any language you need other projects, other resources, and everything else, but for many people Exercism has become the core place to learn a language that other things hang off, rather than one of the hanging things. I see no reason Rust needs to be different.
I feel passionately (see the prefix ) that going through the Rust book, building a Concept Exercise or two for each chapter, and following the route all the other tracks have taken will lead to an amazing Rust syllabus that is incredibly valuable. (So I effectively agree with the core of your idea above). I also feel its the least “reinvent the wheel” approach both from a Rust perspective (the book is probably going to be good) and from an Exercism perspective (I’ve personally put thousands of hours into discussing, experimenting and building content for Exercism - and as a community it’s tens of thousands of hours, so I believe we know what we’re talking about here). I also feel by doing this we’ll be able to elicit support from the Rust community (and possibly the Rust team) and also from other maintainers who are able to contribute if we don’t diverge from the accepted patterns. But I also wouldn’t want our concepts being “See the Rust book” as that goes against how the whole thing works.
So my message is “Trust the process”!
I’ve been saying for ages that having a great Rust track would be one of the best things Exercism could do to improve from a content perspective and I really want to make that happen.
Erik will bring a much more measured approach when you speak to him () but I know he’ll passionately agree with what I’ve written too from his work in supporting all the tracks over the years.
I would also like to participate in breathing some air in the rust track. I’m still learning rust, so I will rely on expertise from others. However I have decent experience in contributing exercises and maintaining a track.
From what I can gather, it seems rust can really benefit from concept exercises. Specifically ones that explore borrow checker. From a quick look, there seems to be quite a few concepts already present with a possibly non-exhaustive list to work on further.
One good starting point would be to create a reference document like in C# track here. This really helps in navigating the repository and keeping track of what concepts have an exercise implemented. Otherwise the knowledge is implicit among maintainers. I can start on this and will create a PR.
What I can say, from learning Rust for months already: Real idiomatic Rust seems hard to learn. Borrowchecker is something you get quite fine when you know about memory management etc. Also those smart pointers and so on. But when is what the best concept to use, is still the most obscure thing for me.
There were already some discussions on Discord. I know about books. But that could be a great chance, to bring idiomatic Rust into such a learning environment.
@iHiD I don’t think there is a lot of disagreement here, or maybe any. I do get why you are worried, and sadly I think you have good reason to.
Here are some more words that hopefully reassure somewhat.
By this I did not mean that something different should be done. Just slightly more.
If, come launch, the syllabus does not cover ownership/lifetimes, pattern matching, str vs. String, and possibly (basic) traits, then you will just get the same complaints as before. These concepts are well-known stumbling blocks in the earliest stages.
So what I meant was:
if you only adapt 10+ concepts from other tracks then the syllabus will not be ready, but
if you additionally cover ownership/lifetimes and pattern matching then it might be.
Hence not enough and slightly more. But not different.
The expectation is that this will be very soon: ownership/lifetimes and pattern matching are both pervasive and unfamiliar. Also the str vs. String conflict touches much example code, which is annoying (but can certainly be worked around).
Regarding pattern matching: there is precedence on the Elm track. (F# less so.)
Frequently it is necessary to understand ownership/lifetimes to be able to even call a function or return a value. Talk about pervasive
Hm. On the one hand: I nor @senekor aspires to planning out something to teach all of Rust. On the other hand: you are using these words for a reason.
Do you mean that Rust syllabus creators have proven prone to getting stuck in thinking mode? That seems very plausible to me.
I agree that this is the way to go.
(Just don’t expect that the syllabus is launch-ready before a specific few of those gaps are filled.)
I do not think it is, and do not expect @senekor to either.
(In fact, I in particular am very far removed from this position. Quite possibly further than even you, @iHiD.)
For comparison: the relevant Book chapter. The Book does not just elaborate more; there is also a lot more complexity – all to do with … ownership and lifetimes.
I expect Rustlings to be an even better resource to look at for this. (Both should be used and referred to.)
Rust is very lucky with such excellent learning materials.
If you ask me, if learn-through-doing doesn’t work for Rust, it isn’t because of Rust.
I do expect learn-through-doing to be harder for Rust in the very beginning. But after grokking ownership/lifetimes and pattern matching I expect it to be the same as (or possibly easier than) for other languages. Which can be soon.
I’m only thinking of this now, but: survivorship bias alert. I’m not saying there definitely is survivorship bias here; merely that there could be. Prolog doesn’t have a syllabus at all.
( I still lean towards Rust (and Haskell) programmers being too dreamy. )
I do not think this; neither does @senekor (probably).
As for the rest of the paragraph: yes, starting with adapting concept exercises from other tracks seems like the way to go.
See the relevant docs (click around) first. Then, I guess, choose a random basic yet missing concept and look for it in this list. Choose the exercise you like best, translate it, and identify prerequisites.
I… actually did think that. Now I know why. I just discovered the concept introduction pages in the actual UI ! (The little concept badges are clickable! Who would’ve known!)
I hadn’t talked about this yet, but my experience was that even the Elixir track doesn’t really teach the concepts, but drops you into the exercise with a “Just start writing some code!” approach. My thinking was, maybe that works for a language like Elixir, where the language is kept simple by design. It surely won’t work for Rust.
Turns out that impression was just me not understanding the UI. The Link @iHiD posted to the introduction to anonymous functions made me suspicious, I’ve never seen anything like it. So I went back to the Elixir track to search for it.
These questions may warrant their own thread:
How many other people misunderstand the UI and skip the theoretical introductions entirely? How big is this problem?
Is there an easy way to fix it, without making the UI much more complicated?
Since the syllabus is disabled on the Rust track, is there a way to enable it only for certain users, while the syllabus is built, as someone new to Rust, I can go through it via the UI and give feedback.
A small update, I’ve been implementing following concept exercises & I’ve started pushing PRs for some of these.
annalyns-infiltration (booleans)
cars-assemble (if-statements, numbers, )
log-levels (strings, for-loops)
phone-number-analysis (strings, tuples)
tim-from-marketing (option)
high-school-sweethearts (string-formatting)
interest-is-interesting (floating-point-numbers, while-loops)
Not sure about this one. Not producing the right precision might be confusing for learners.
The planning document and some of the exercise PRs have a lot of csharp remnants.
There are some Rust specific explanations of the concepts themselves in there, but these should go in the concepts directory I think, instead of the exercise instructions.
The concepts directory seems to have a bunch of concepts without corresponding exercises, those would need to be incorporated into the planning document.
Here are the corresponding PRs. The primary objective is to create a very simple exemplar implementation with working tests for all the concepts along with introduction.md, instructions.md, hints.md as well as some .meta files.