[aussiesnack]

> The vast majority of beginners can just learn "& means any number of readers and no writers, &mut means one writer and no readers".

But 'beginning' is never the hard part of learning any programming language, at least for a programmer. The hard part is going from having learned the basics to getting stuff done. Rust is harder than any other mainstream language to do that in. The writers in that thread can't even describe their mental model (NOT the underlying tech as you claim) of lifetimes without vast elliptical descriptions. And they can't point to any straightforward documentation.

I have learned multiple programming languages, of many different paradigms, and never had the trouble getting to the stage of writing useful software that I have had with Rust. I've witnessed the same again and again with all the people I know - all professional programmers. In fact I'm the only one I know who's stayed with it.

I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange. Odd enough (and distant enough from the obvious, adn the experience of every person I've known) that I find it completely incomprehensible.

[nicoburns]

> Rust is harder than any other mainstream language to do that in.

I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc).

> I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange

Some of us just didn’t find it that hard. Like, I get that its hard for people in theory, because I’ve seen enough people express this that I believe it must be a common experience. But my personal experience was a couple of weeks of slow progress and lots of puzzling, and then everything became much easier, coupled with a joy that most of the language is so much better designed than the previous generation of languages I was used to using (e.g. it actually has sum types, and everything is an expression - why on earth doesn’t every language work like this)

[jandrewrogers]

C is a simple language. Many people have quickly become proficient at it with only K&R to work from, and that is a thin book. The C language has many deficiencies but I don’t think many people would characterize it as difficult to learn among its peer programming languages. It has very few concepts that you need to learn.

C++, on the other hand, is exceedingly complex and a difficult language to become proficient in, though modern C++ is an improvement in that regard. Some of this is due to decades of legacy cruft, some is due to it being an atypically expressive systems language, all of which has been stirred together.

[aussiesnack]

> > Rust is harder than any other mainstream language to do that in.

> I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc).

Agree I overstated that. What I mean is that, out of the difficult to learn languages, Rust is the only one whose community for opaque reasons denies the difficulty.

> Some of us just didn’t find it that hard.

Why the difference I don't know. So far everyone I know who has learned it has dropped out because they just couldn't get practical traction with it. My guess is that most people who say they don't find it hard are either longstanding C/C++ programmers, and/or are learning at work where they have immediate help & scaffolding.

What is odd is that rather than responding to difficulties with a curious "Oh, I didn't find it hard, I wonder where the difference lay", Rust advocates tend to come back with an aggressive 'proof' that Rust is factually not hard to learn (with implications we can all guess at). No other programming community frequently does this in my experience (and I have brushed against many). That community attitude itself must have causes that are worth thinking about.

[insanitybit]

The rust borrow checker has been described in trivial terms many times. The first time I had it explained, as I recall, was as a book.

You own a book.

`&` - You can lend others the book, they can't fuck with it. `&mut` - You can lend the book to one person, they can fuck with it `move` - You give someone else the book, it's theirs now

Or `many reader NAND one writer`

Is this a complete explanation? No. But it's quite simple and you can be plenty productive with just this amount of understanding.

Your experience is not my experience. I used Rust for the first project I wrote as an intern after dropping out, having never used it before, and I even used it to interact with mysql, which I had never used before.

At my last company I had multiple people pick up rust in a matter of days.

I'm not denying rust as being difficult, I'm saying it's easy for some and hard for some. I found it easy, I was writing productive code on day 0 with virtually no preparation other than that I wanted to try it out. Many people find it easy. Obviously some people, many people, find it hard. Life's weird like that.

[legerdemain]

OK, simple issue that a beginning Rust user runs into immediately:

  - function arguments are moved into the called function

  - you can call a function with a ref, and then you can keep using it in the calling function, because there is a blanket impl of Copy for refs

  - you can call a function with a ref mut, and then you can keep using it in the calling function because ... ???

[jcranmer]

From the standpoint of being productive in Rust, this is what you need to know:

* An object has a lifetime. This generally lasts until overwritten or destroyed at end of scope.

* You can loan out references to this object. You can either have a single &mut, xor an unlimited number of & references, but not both.

* References cannot outlast the lifetime of the object they point to.

* If you have a &mut reference to an object, you can give out another &mut reference to the same object. But you can't use the first reference for the duration of the second.

* Lifetimes can be named, and you can express criteria of the form "this lifetime must at least/most this long."

* Bonus: if you have &mut x, you can give out &mut x.a and &mut x.b at the same time. But you can't give out &mut x while such a subreference is live.

And... that's really all you need. Yeah, there's a lot more rules, and there's definitely fun edge cases around things like temporary objects' lifetimes. But there's no need to know all of that stuff. If you get things wrong, the compiler will come back and slap you in the face and give you an error message--that's the selling point of Rust, getting lifetimes wrong is an error, not silent nonsense--and your task at that point is to figure out if you're really breaking a cardinal rule (two or more mutable references to the same memory location, or references not lasting long enough), or if you didn't enforce sufficiently strict requirements for the bounds of the lifetimes. And the rust compiler is pretty good at telling you what you have to do to get necessary lifetime bounds (sometimes too good--it can suggest fixes to lifetime bounds even when such bounds are unachievable).

I'd compare this to things like name lookup and overload resolution in C++, which are actually horrendously confusing algorithms that almost nobody understands in their entirety. Yet plenty of people can be productive in C++ because the general principles are well-understood, and if you're at the point where you need to descend into the morass of exceptions and exceptions-to-exceptions, you're probably writing confusing code to begin with.

[aussiesnack]

But I've never heard a C++ programmer deny that it's a large and difficult language.

I personally never really had a problem with ownership model - probably because what I was doing fell into the simple buckets. Rust's difficulty goes well beyond ownership. I just thought the Rust user forum thread I quoted was a gently funny example of the Rust community's denial: "Rust's not hard, but to get a decent mental model of the borrow checker you need to read the standard library, or if not here's 10000 words on how I think of it". I'm not presenting it as "proof" that Rust is hard - the fact that I couldn't do anything practical with it after more troublesome attempts than with any other language is plenty enough for me to know that. Neither do I think difficulty is 'bad'. Denying it can be though.

[zozbot234]

> Rust is harder than any other mainstream language to do that in.

It's not hard, you just add boilerplate. Cloning data, using interior mutability, or adding ref counting to deal with cases where multiple "owners" can keep an object around independently.

Then removing the boilerplate is how you do optimization, once you've gotten things to work. The opposite of other languages where low-level code is the most verbose and least intuitive.

[aussiesnack]

> It's not hard,

Yep, that's the standard Rust aficionado flat insistence: "You're finding it hard. You're just wrong". Yet with more learning time than I've put into any other language I've learned, I have been unable to use Rust for real (ie. beyond beginner toys). A quick count of langs I've used professionally comes to about 10; I've learned many more to play with, much more successfully than with Rust, in much less time than I've spent with Rust. This reflects the experience of everyone I know who's tried it out (I'm the last man standing, having another crack at it this year).

The cultural peculiarity of this is that, in a field that generally lauds effort and intelligence, Rust advocates uniquely consider 'hard' or 'difficult' to be negative criticism. I don't hear this from (say) Haskell or Scala programmers. I certainly don't consider difficulty a negative - it depends on whether the payoffs are commensurate, and for Rust I think they are (I'd just quit otherwise).

As I'm 100% satisfied (no matter how often I'm unconvincingly 'corrected') that Rust is indeed harder than most programming languages to learn, I can only categorise this peculiarity as denial. Denial usually has ideological origins. I'm not entirely sure what they are in this case, though I have some ideas. These do feed into a sense that although I like the language, I don't think I like the Rust community much. I get strong religious/culty vibes from it - similar to the worst of the Linux community (for the record I also am a f/t Linux user, and I think that community has moderated considerably over time).

[TylerE]

Ok, so how do I do one writer and one or more readers?