Normally i tend to write long, in-depth articles on technical topics involving Rust, but after reading about Daily C++ I've started building up a stockpile of smaller articles I can use to help my coworkers improve their Rust skills.
This is the first such article - an introduction to a nice quality-of-life feature, Slice Patterns.
On a quick reading of "Slice Patterns" I wonder if you could make that "Weekly Rust". There is enough syntax and semantics in there it will take me a week to comprehend it all !
My original inspiration was from this article on Jonathan Boccara's blog, Fluent C++, where he approaches teaching by giving people quick, relatable, bite-sized lessons.
Exploring different elements of the language's syntax would be great material for a Daily Rust series, although I feel like it'd take me several years to adequately cover semantics or the various patterns that emerge.
I was just thinking, I wonder if a forum topic that you posted all of the posts to would be useful. Kind of like the Rust Gamedev post. Then we can subcribe to it to get updates. I could maybe use RSS or something, if that was setup on your blog, but I don't really use RSS for anything else so I'd probably never actually get to it.
Ah, hmm, well, I don't believe it is possible to be fluent in C++. That language is syntactically and semantically huge and complex. And it gets more so every few years now.
For sure it has been sprouting many features to make this or that more convenient in some situation. But every one of then comes with a few dozen rules as to how to use them else thing goes badly wrong.
It has been amazing over the years to watch so many presentations at C++ conferences where the whole talk is about how to not get into a mess with whatever language feature.
The last straw for me was when Stroustrup himself could not see a problem in some C++ code on a presentation slide during some talk.
I get that kind of worry about Rust when reading an article like "Slice patterns".
Very nice and all, but the static and semantic understanding overhead of the short cuts the language allows seems to be greater than just writing simple code to do the same in C or Pascal or whatever.
TLDR: I'm worried that Rust goes down the language bloat road that C++ did.
I'm not somebody who is super informed about the direction or guidance on how language features are added to Rust, but I feel that most of the Rust language that has made it to stable really has been well thought through. Nothing is perfect, but I do feel that the Rust team and community have done a pretty good job at keeping Rust sensible and that they will probably continue to do so.
I can understand the sentiment, but I think it all depends on your background. For example you have a background in C-based languages where pattern matching is a foreign concept, whereas it's an integral part of control flow in most functional languages (see Scala, Haskell, etc.).
It would be akin to saying C's ++ operator or switch statements are unnecessary shortcuts because they could easily be written as x += 1 or a big if-else chain.
Exactly. If a new language, say Rust, is to accommodate every feature/style of every potential users background then I suspect it will become a horrible mess where everyone has to be fluent in every style of every language in order to understand any code they come across.
A nightmare like the Biblical story of the Tower of Babel.
A saving grace for Rust, which I am now heavily invested in, is that its strict rules about types and aliasing (the borrow checker) will not allow crazy language feature suggestions to get a look in.
That is to say, Rust's foundations are solid. As opposed to C++ whose C foundations are certainly not.
In this case I'll argue that the slice patterns feature:
Makes Rust more consistent, because it's essentially pattern matching on sequential values. Matching on regular values was already possible, and this helps make pattern matching a more complete feature.
Can make code simpler, as argued before.
Especially the first point shows that it's not necessarily a shortcut at all, though I can see how one could view it that way.
Sometimes I share that concern. But for most features so far I can not only read an RFC and see the complexities involved, but also the reason(s) the feature was added in the language. Knowing such things helps a lot, at least for me.