Flattening Rust’s learning curve

Technically that's a bit closer, yes, but way more people have heard of char* than string_view, and char* is similar _enough_ to &str that the analogy still works.

If you're in hard realtime land then you can't have any allocations at all; that's a pretty different ballgame.

Destructors should be as simple and side-effect free as possible, with the exception of things like locks or file handles where the expectation is very clear that the object going out of scope will trigger a release action.

My feeling is that Java / C++ / Python / Javascript are all really the same language when you get down to it. Rust borrows from OCaml more than an other popular imperative languages (the first implementatoin by Graydon Hoare was in OCaml, so the inspirations abound), and therefore it really is quite different to a lot of devs who have never seen the functional paradigm. Good rust is written as a mix of imperative with a strong functional flavoring. Bad Rust is when you try to do everything by mutating arrays over iteration as you would do in imperative languages.

For me, I almost never write "for loops" and "if statements" in Rust; instead I use "functional iterators" and "match expressions", which interface with the borrow checker more nicely.

For example, iterating over an array while modifying it is a common pattern in imperative languages that compiles fine but often causes hard to reason about logic errors during runtime. In Rust, such a thing would cause compile time errors. So instead you rewrite to be more functional, it compiles, and then the magic is it just works, which is a common property of functional languages like Haskell.

IMO a lot of the consternation about the cost of the learning curve is because developers haven't realized once you get past it, the benefit is your code more often is just correct and therefore you run into fewer runtime bugs. In other languages you get the code compiling faster, but then you spend a great deal of time debugging things at runtime which you didn't anticipate at compile time.

I agree that if you're using macros to create unnecessary levels of indirection that make things more difficult to reason about, that's not advisable. One shouldn't do that with macros or any other abstraction.

With functions for instance, sometimes people get carried away very straightforward linear code, and atomize it into a hundred little functions that all call one another, all in the name of reducing code duplication. Doing so is an abuse of functions, but one wouldn't say that functions should be used sparingly.

I think that macros are an area where many programmers don't have a lot of experience, and so they also throw out some best practices in order to wrap their heads around what they're doing.

But macros can be very helpful if properly applied, and Rust makes that more ergonomic, and safe, to do.

For example, if I have to write 100 functions that all are similar in structure, but have a slightly different function signature. I would reach for a macro. I don't think it reduces clarity at all, and it increases maintainability because I don't have to change code in 100 functions if an adjustment needs to be made.

Another area where macros is very useful is in creating DSLs within Rust. This is usually the domain of LISPs, but it's an ergonomic way to write tests little scripts.

I seem to have eased into a rust programming style that dodges these, perhaps at the cost of some optimizations. Using the first example, for example (The article suggests this): Don't return an `&str`; use those for transient things only like function parameters; not for struct fields or returned types.

I'm starting to wonder what I'm missing out by doing this. Not addressed in the article: Any tips for using the more abstract features, like Cow etc? I hit a problem with this today, where a lib used Cow instead of String, and the lifetime errors bubbled up into my code.

edit: I found this amusing about the article: They demo `String` as a param, and `&str` as a return type for triggering errors; you can dodge these errors simply by doing the opposite!