Rust is for Professionals

Here I am on day three of an attempt to modify a rust program with logic that would have taken about twenty minutes to implement in C# or Java. It has to do with operations on strings (use a regex to find a string in some text, escape all the regex-reserved characters in that string, then use the string as a regex to find other occurrences of itself in the text) so I get that I'm really thrown into the borrow-checker deep-end, but man writing rust feels like working on one of those puzzles where you try to fit a set of tiles inside a rectangle. You'll almost get it but then some edge is sticking out. So you move the tiles around but this leads to two edges sticking out now! So you do a whole bunch of additional exploring before ending up right back where you started with the one edge sticking out.

I even abandoned the learn-by-stackoverflow-search approach to rust and read the first seven or so chapters of the rust book. But even that hasn't helped very much. I know I am just currently in the painful, frustrating stage of learning where nothing really makes sense, and at some future point it will all click, but it really can't be overstated just what a wicked learning curve this language has.

The author specifically and explicitly pointed out 3 times in 2 paragraph that these were new to them, not to the world at large. In fact, they spelled this out very explicitely in the paragraph following the one you selectively quoted:

> Many of the new concepts weren't novel to Rust. But considering I've had exposure to many popular programming languages, the fact many were new to me means these aren't common features in mainstream languages.

And… they're right. Other languages cropped up with overlap around the same time (mostly Swift), but sum types, pattern matching, option types, … were not common features, and borrow checking remains rather unique.

While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thinking about it (as they are called automatically).

This is a nice summary of the good features of Rust, but I'm failing to see how any of these points are in any way special for a "professional programmer". Doesn't a hobby programmer care about all of these points as well?

In my experience, whether you're getting paid or not correlates quite poorly with the requirements of the project. I've worked on professional code bases where bugs were totally acceptable ("just push a fix when the error comes in"), and I've done open-source projects where I definitely don't want anything to break ("I'd hate to release a broken version").

> The statement Rust is for Professionals does not imply any logical variant thereof. e.g. I am not implying Rust is not for non-professionals. Rather, the subject/thesis merely defines the audience I want to speak to: people who spend a lot of time authoring, maintaining, and supporting software and are invested in its longer-term outcomes.

Well, it looks like you're implying some logical variants, like "Rust is a better language than language X for professionals" or "Language Y is _not_ a language for professionals". I mean, "Language X is for Professionals" is true (by observation) for every single language out there being used professionally.

I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write.

I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.