I find that as a C++ programmer, Rust encodes in the compiler a lot of best practices about ownership and memory management. Using Rust is a breath of fresh air in not having to worry about dangling references.

From experience programming C++, I can see what the error messages are trying to prevent and why it is important.

However, if your experience was primarily with managed/garbage collected languages, a lot of the Rust compiler pedantry is stuff that you never had to worry about to being with and you have never experienced the pain it is trying to prevent.

You covered the downsides pretty well, big upsides for C++:

- ability to use C libraries directly - and thus original C API docs. I've got battlescars from NPMs deep dependency trees, and cargo is a similar story.

- I don't need the (very patient and knowledgeable!) people on rust discord to hold my hand every day. There's a stackoverflow for almost every C++ issue.

- that 5% edge case where the codes safe but the borrow checker isn't happy I can just write. No RefCell or nightly compiler.

This is something Rust is relatively good at, you just may need some unsafe blocks, but assuming you can compile using clang for the C code everything tends to work well. I am saying this as a Rust skeptic.

It sounds like you're making a common misconception here. unsafe code and the borrow checker are not closely related, and unsafe blocks are not a way to play fast and loose with ownership issues. See https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

If you don't want to deal with the borrow checker, the solution isn't unsafe, it's Arc, Clone, RefCell, etc.

This is a red flag for your complains: Is VERY likely you believe Rust is wrong, when the fact the problem is that your code is not good.

I know this, my first 3 months starting Rust were thinking between "I'm a failure as developer" and "Rust is wrong" or "What? Why can't do this?". For first time after learning more than 12 languages I was truly in shock. And even, for second time in 20 years, picking a book and PAYING attention to it.

THE major problem with Rust is not, not even close, the borrow checker or that is picky. Is that Rust idioms are not OO idioms, not C/C++ idioms, not PHP idioms, no Java idioms.

Is fairly a simple language, actually, and the productivity is very high (today I code in Rust faster than python, that is still my benchmark on productivity).

What is NOT simple, is that it require several things to "click" and align properly to make the journey smooth.

And that it reveals how much other langs hide for your.

P.D: The problem you say, sometimes are true, but only at first, when the people are not fluent on the lang, or later, when doing seriously advanced stuff.

Not think I bashing you. This experience is common for many in the community, and even very strong developer get the weird experience with Rust. But also is true that when Rust "click" is very, very good!

P.D.2: I bet Rust is much harder the more experience a developer is and the more ingrained some ways are. I teach Rust to some newbies, and the experience for them is far smother.

I'm gonna be blunt: This is the worst thing to come out of the Rust community, bar none. Rust is a fine language and I love to write in it, but I loathe the way Rust developers have convinced themselves that Rust is an axiomatically 'better' language and that the things you can't do in Rust, or the things that are painful to do in Rust, are a perfect circle venn-diagram overlap with the things that are just bad to do in general. It's a mindset that shuts down discussion and constantly shifts goalposts. It doesn't help anyone.

Who knows, maybe rust clicking for me was just around the corner. I kept thinking "finally I'm understand this" and then something else would happen.

I'll leave it to the incredibly patient programmers who can spend 3 months just learning it. I'll use all the time I save to write more tests, and probably end up with something much more correct.

After all, you are human, and we humans aren't good at exhaustive covering of all bases. Sometimes when I am reading a rust compiler error message about erroneous borrowing I really wonder that I never could have thought about that corner case.

It's true. Sometimes Rust compiler's pedantry is just not neccessary. Then write Python, TypeScript, Ruby or in Rust box, arc and clone everything.

I understand, I was close to drop it.

In retrospect, I create a lot of self-inflicting problems in my journey (like I learn Rust making a programming language and hit by coincidence some of the hard stuff with Rust!) and knowing what I know now, Is clear the time running in circles was in big part that.

But, of course, is hard to see you are running in circles when you are running in circles :(

The instances of safe code that the borrow checker can't verify as such are not "corner cases" by and large, they're genuinely non-trivial patterns, often with non-obvious drawbacks such as lack of composability/modularity. Rust devs and researchers are working on better abstractions to support those cases, but these are very much the exception, not the rule.

> people routinely write more inefficient code to satisfy it

People should stop freaking out about this. The "more inefficient code" you might get by adding a few .clone() or Rc<RefCell<…>> when the borrow checker complains about something is still way more efficient than anything written in alternative "safe" languages.

The "slow" solutions are a bit noisy but that's a good thing, since it tells you where it might be worthwhile to either refactor for efficiency or document why a refactor isn't feasible.

Unfortunately, the borrow checker can't handle a basic observer without falling back to patterns that violate encapsulation. The observer pattern is one of the best patterns for composability/modularity, and I find that the borrow-checker-compliant solutions are more complex and don't solve anything but rather move problems somewhere else.

It's cases like these that make me appreciate Rust's wisdom of adding Rc<RefCell<T>>.

But you don't have to use a "safe language". C++ can avoid a lot of copies and be just as safe from an absolute point of view. The borrow checker isn't god and Rust isn't perfect. In an absolute sense the C++ code you can write could be more correct and efficient(it just doesn't tend to be).

That's Godel's incompleteness theorem for you. Every static type checker also rejects valid programs, but that doesn't make them any less useful. Just one of those inconvenient facts about our universe.

Yup, this is the tradeoff you have to make to catch the wide variety of bugs. For personal use, probably not worthwhile, but it definitely pays off for the safety it provides in production contexts.

The way I view Rust's philosophy is "it's better to catch bugs at the compile stage than at the execution stage".

In theory yes. In practice, getting to the execution stage was such a slog that it rarely happened.

Would have liked it a lot better if the borrow checker had the option to be -Wall instead of -Werror.

> Would have liked it a lot better if the borrow checker had the option to be -Wall instead of -Werror.

Wouldn’t this defeat the purpose of the borrow checker and remove the guarantees the language gives you?

The software is a layer over an in-process key value store written in C (LMDB).

Seems like your argument is Python catches some bugs when converting to bytecode, so it cares about catching bugs early. That's not true -- for the most part, Python catches only the most trivial of typos before execution.

Type checkers provide tools that make it comparatively easier to ignore when they could be wrong or are getting in the way. To do something in a type-safe manner often doesn’t require re-abstracting behavior.