[steveklabnik]

We don't just add things for the sake of adding them. Most new features are being driven by two things:

1. Making the language friendlier for beginners and easier to understand.

2. Addressing pain points by production users.

That being said, I'd push back a little on "number of features" as a measure of complexity. There's a few ways in which this is a problem.

For example, the "waterbed theory of complexity", that is, if you make the language simpler, you push the complexity elsewhere. This can be good or bad, depending. I generally hesitate to compare Rust to other languages, but there was a good illustration of this the other day, about Rust and Go: https://news.ycombinator.com/item?id=17618918

Basically, Go has kept the language incredibly simple. Rust has added many features that Go does not. But that means that error handling in Go is significantly more verbose than in Rust. You can't just wave away the inherent complexity of properly handling errors; it has to go somewhere. Both choices are 100% valid, just different.

The other big issue with simply enumerating features is that cohesion and orthogonality is important. C++ did something truly impressive; they changed the fundamental model in which you write code. Idiomatic C++98 and idiomatic C++17 look and feel very different. The cost of this is that many features don't quite fit together as well as you would like. Or at least, that's what people say. We try to really make sure that features fit together in a way that makes sense.

Time will tell if we succeed.

[andrepd]

>We don't just add things for the sake of adding them.

I hope you realise that the C++ design committee also doesn't add things for the sake of adding them. They aren't morons. Often there is a very real tradeoff in every decision, but generally the motivations seem to also be those two you mention.

[elteto]

I honestly disagree. When Bjarne writes a paper [0] saying how C++ is going the crumble under the weight of disparate and incoherent features then the language and its wider community has a problem.

To quote:

    The foundation begun in C++11 is not yet complete, and C++17 did little 
    to make our foundation more solid, regular, and complete. Instead, it added
    significant surface complexity and increased the number of features people
    need to learn. C++ could crumble under the weight of these – mostly not
    quite fully-baked – proposals. 

[0] http://www.stroustrup.com/P0977-remember-the-vasa.pdf

[steveklabnik]

I was hoping that my comments about C++ specifically would make that clear, but yes, I also very much agree that the committee doesn't do things just because. I have a very deep respect for their work.

[mrpippy]

> I hope you realise that the C++ design committee also doesn't add things for the sake of adding them.

There was a years-long effort to add a 2D graphics library to the C++ standard library.

[infogulch]

   This paper proposes a web_view facility for the C++ standard library.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p110...

Yes, web view and standard library are being used in the same sentence. How on earth a web view might be considered for inclusion in a standard library is beyond me.

[steveklabnik]

In-context, this makes a bit more sense, though I'm not sure I'd vote for this proposal if I were on the committee. The introduction does a decent job of explaining the motivation; this is an alternate to the long-going discussion about putting 2D graphics in the standard.

Getting outraged at proposals, especially from the outside, doesn't make for a healthy process; not every proposal becomes accepted. Off-the-wall proposals can sometimes help explore a problem space with a new outlook. That doesn't mean that every single proposal is worth taking equally seriously, but Hal is a well-known name in this space, and has done a lot of good work.

(Incidentally, this kind of situation is why we're interested in adding stages to Rust's process; we want clarity around the maturity of a proposal. Some proposals are just for brainstorming. Some are more mature. It can be hard to tell sometimes from the outside which is which.)

[baby]

> 1. Making the language friendlier for beginners and easier to understand.

make documentation a priority! With Elixir or Golang you can access doc super easily from the command line. Some sublime text plugin shows you the doc for highlighted std functions as well. These are what make a language awesome imo.

[steveklabnik]

It is literally my job to make documentation a priority. We're on the same team here :) I spent the last 18 months throwing out an entire book I wrote to write a new one that’s oriented around how real users learn the language in real life. We’ve invested a lot.

(Some editors do have inline doc showing support; we don't have terminal doc access but we do have local html doc access)

[baby]

It's good to hear :) I hope my suggestions are helpful

[pornel]

BTW:

    cargo doc --open

opens documentation for the current project, including all its dependencies. Rust generates docs in HTML. While it doesn't stay purely in command line, it enables cross-linking, collapsible sections, and has built-in search.

[bluecalm]

Why do you prioritize making things easier for beginners? I mean, it's a system language many people are going to choose to code advanced performant stuff. Wouldn't it make sense to prioritize programmers who are going to build important stuff in it?

[steveklabnik]

Beginners to Rust, not people who are new to programming, sorry that was ambiguous! We are putting basically zero effort into "learn programming via Rust."