sreevisakh

> Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. These are not familiar concepts to most people working in other common languages, and there is a pretty steep learning curve, even for experienced programmers.

Rust's borrow checker system doesn't exist in isolation. It's designed to avoid problems that can occur with computing and memory model of programming - things like call stack frames (esp constant size), heap memory and other resource management, concurrency paradigms, etc. These are just the tip of low level computing models. There are things like cache coherence that Rust doesn't address directly. These are concepts that programmers must know if they want to do: a) Low level programming b) High performance programming. The problem raised by author may partially belong to the second category. Even if it is not, programmers should probably learn these, because they are likely to face such problems at some point and may gain from that knowledge.

There are two ways to learn the borrow checker rules. The first is to start with the rules itself. It's going to appear rather convoluted. The other approach is to understand the machine/memory model that I mentioned above first. Once you do, the rules are going to make much more sense - especially in the context of specific error messages during coding. These days, I'm able to connect every single error message that I see to some potential memory or concurrency problem, even though they are the result of some seemingly convoluted but simple borrow checker rule.

> Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below).

There were dozens of errors that I made today that were easily understood just by a glance at Rust's error messages. The help messages that accompany these error messages are often the solution that I needed. Even otherwise, the error messages point out potential low-level bugs as I mentioned above - allowing me to make proper corrections. This may just be anecdotal. What is not anecdotal is that the Rust team reworked the error messaging early in the project's life to make it that way. It's generally accepted that Rust's error messaging is top-notch. I find it disrespectful to all those early endeavors to call it arcane. Perhaps it's a good idea to try to learn those error messages. There is an entire index of errors with detailed explanations [1].

> We started having weekly “learn Rust” sessions for the team to help share knowledge and expertise. This was all a significant drain on the team’s productivity and morale as everyone felt the slow rate of development.

Perhaps this is the wrong way to approach the problem. The thing that may need learning is type theory. Type theory is often too esoteric with a theoretical mathematical approach. Perhaps we need an introduction to it that encourages people to see a bunch of bits as a storage for data with a particular meaning (the type). Next step would be to how to track types using software (type system) and then extend the idea all the way to include constant-size stack frames, generics, polymorphism and lifetime tracking.

> Libraries and documentation are immature

Library ecosystem is still growing - especially async programming. But documentation support is a first-class feature of Rust's language ecosystem. I find myself writing documentation much more often in Rust than with other languages. It's also equally easy to browse the documentation of the language, stdlib and other libraries. Sections are marked out clearly and navigation is well thought-out. Every search of a feature or API takes me through half a dozen links to the final target in a matter of minutes, if not less. It's a good investment to learn browsing technique for documentation in any language.

> Rust makes roughing out new features very hard

Somehow, my experience doesn't match here either. I use the same technique for trying out new features in both Python and Rust. Create a scratch project for each experiment. A single project may take up to a dozen such scratch projects. It's marginally easier in Rust than in Python, mainly because project management is another first-class feature of Rust tooling.

But what's really remarkable about Rust compared to most other languages I've encountered is that Rust's discipline gently nudges the scratch project to a proper design. By the end of the scratch project, the experimental code is often in a good enough state to be directly integrated into the main project. It's amazingly friction-less to integrate integrate external code into the main project.

I wouldn't blame the author for having a very different experience as mine. But I sure would like to know what makes Rust 'click' for some, but remain a tough nut to crack for others.