"Simple" can mean many things.

For me Rust is "simple" because it has great tooling / great diagnostics, so when I get something wrong, most of the time it can tell me exactly what it is (and how to fix it!), and only occasionally does it send me down a rabbit hole.

Rust is also "simple" because it's memory-safe - if I can get something to compile (without unsafe code), then I know there's no use-after-free, double-free, buffer overflows, etc. I can concentrate my mind on the business logic (where bugs still can and do happen).

Finally, Rust is "simple" because it lets me build abstractions so I can see more clearly what I'm doing. At work we had a Go codebase full of goroutines and channels - I got tired of it and did a proof of concept in Rust: now it's just one async Stream, you can see the data flow clearly and worry about each stage of the pipeline in isolation, instead of having to jump across many different source files.

But no, it's not all very simple. There's plenty to learn, and some of the core concepts (ownership / lifetimes) are fairly hard to wrap your mind around, even if you've encountered something similar in other languages. My take is that it's worth it - you'll be very slow at first, but as you get more comfortable with it, so will you get faster.

(For context: I teach Rust since 2015)

Rust is "simple" in that it is based on a few solid principles. Data with layout, Ownership of the data and the distinction between sharing and mutability (through immutable references and mutable references). Most of the interesting API in _some_ way leans into that. So, the _basics_ of Rust are indeed quite constrained.

But that's "simple" in the sense of "Ruby is simple, everything is objects and message passing".

But then: Generics introduce a ton complexity on top, because they open a space where you are _potentially_ in a borrowed _or_ an owned situation. There's tons of tiny optimisations and protocols: for example that `Box<[u8]>` exists and turning it into `Vec<u8>` comes basically for free. There's tiny details like compiler assists that sometimes trigger and sometimes not. But even Generics can also be seen as an application/extension of the basic principles.

And then, there's tons of tooling and language that you need to know. Standard traits and features of the stdlib. Clever applications of Ownership based management for handles.

And particularly Rust is (currently) not _easy_, because the programming environment has fundamentals that are unusual to program that you cannot bypass as a beginner. That actually changes, the more those practices get known to people and individuals can teach each other rather than finding out themselves.

I think what people say when they say "Rust is simple" is that they can break down any house to a limited set of bricks. That is certainly true. But that needs a level of proficiency with the language. So, telling beginners "look at Rust, it's simple" is harmful - it's full of combinations and applications of its language core and it will take quite some time to learn breaking that down for people and figure out which tool is for which moment.

> this is something that can change from person to person yes, but is it like that for you?

In my opinion it really depends on your background.

For example, Rust uses the `i32` type as the standard integer. If you come from a C/C++ background this is probably not that weird, you probably know how many bits there are in 4 bytes off hand, there's `int32_t` standard types and you probably have experienced not wanting an integer with a variable size that depends on the platform.

If however you come from Python, Javascript, or maybe even Java, this might range from a little weird to very weird. Python only has the `int` type, no unsigned types and you might not know how many bits make up a "standard" integer, or even exactly how bits, signedness and integer sizes fit together. Java doesn't have unsigned types and doesn't have issues with sizes depending on the exact platform, so they might not understand why you would want the amount of bits right there in the type name.

This is just for the standard integer type. If you consider how many design decisions are a direct result of working on low level, high correctness required C++ code, the "simplicity" could range from completely simple to very much not simple.

IMO Rust is much easier and simpler than C++, but much harder and more complex than any managed GC language.

I don't think it's simple. I find lifetimes especially challenging. I love rust, but sometimes I am remarkably unproductive in it because the compiler is so strict. Honestly, sometimes I think I need flash cards for memorizing how to deal with particular compiler errors.

Lifetimes are an interesting illustration. They are conceptually surprisingly simple (they draw regions in time and check if one region is clearly smaller than another), but as a language feature very weird, as they are essentially a declarative language in an imperative setting. A lot people struggle with them more because they can't really _place_ the feature rather than applying it.

It's a west-coast tech industry consortium language that is a mashup of subsets of SML, C++ and Cyclone with some very strong opinions about aesthetic differences. "Simple" is not a good description. Lisps are simple. Rust, Java, C++ & friends are not. Also, the core paid promoters of rust are almost all alumni of the Ruby on Rails hype-train. You can judge for yourself if their promotion of rails was grounded in truth.

SML doesn't have typeclasses/traits, so it's fair to say "Haskell" instead.

SML has signatures. In the absence of HKT, I think it's not a fair comparison. Most popular languages have interfaces even if not by that name. Haskell, Scala and C++ are special in that you can describe an interface for interfaces. I'm sure I'm not giving due credit to others.

Rust has paid promoters?

We do not, but sometimes people who want to disparage me, Rust, or both, say stuff like this. It was said a lot more often in the earlier days.

Well, I certainly wasn't speaking about you specifically. However, did you not say that language promotion is what you do and that you quit Mozilla for not paying you enough for it here: https://steveklabnik.com/writing/thank-u-next ?

"promotion" doesn't appear in that post. My job was writing documentation. I did say that I was considering moving into evangelist/growth roles. My next job wasn't those two though, it was PM.

I guess you were trying to disparage Yehuda, then?

I mean that you are one of several. Hence the running joke is the "Rust Evangelism Strike Force" and not "that one rust guy."

An evangelist/growth focused role is exactly what a promoter is. If you spend large numbers of typical work-hours, which I'm assuming you're paid for, on social media to promote something, like Rust, or you go to conferences and events to speak publicly in promotion of something like Rust, then a "paid promoter" seems like a pretty accurate description.

Is that disparaging? Is that not what you are doing right now?

> An evangelist/growth focused role is exactly what a promoter is.

Right. move into. Because that was not a part of my job description at Mozilla. They didn't dislike the stuff I was doing, but it's not my work.

The disparagement is the implication of lying:

> You can judge for yourself if their promotion of rails was grounded in truth.

Given a 15 year retrospective, would you say that Rails lived up to the hype? If you think so, then there is nothing “disparaging” in that comment at all. If you don’t think so, then doesn’t that mean a reader should not regard such promotion with confidence? No need to be defensive.

It can be disparaging to say that someone is doing a thing because they got paid to, when they were not in fact paid to. Even when that thing, by itself, is not bad.

In this case it implies dishonest astroturfing or similar, especially when you talk about whether their statements were "grounded in truth". (Which is different from whether Ruby did well years later.)