I'm afraid of rust adding too many features for its own good like c++ did..
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.
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.
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.
This paper proposes a web_view facility for the C++ standard library.
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.
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.)
There was a years-long effort to add a 2D graphics library to the C++ standard library.
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.
(Some editors do have inline doc showing support; we don't have terminal doc access but we do have local html doc access)
cargo doc --open
For example, many users were confused by Rust's module system, because modules behaved differently than in other languages. The 2018 edition added the "missing" features to the module system to meet expectations that new users have.
The end result is that Rust 2018 is easier to learn.
Rust has been adding features for 30 releases now, and every new release has been easier to use and easier to learn.
People added features to languages like scheme, ocaml, lisp for decades, and it was fine. There are type systems for racket, object system for ocaml, pattern matching for lisp, all of which are simple and fit into the design of the language well.
The problem with C++ is that it was based on the C language, which already was an example of terrible design (by modern standards), and new features also were half-baked or badly designed (SFINAE, accidentally turing-complete templates, 666 *values, too much implicitness and unnecessary entities, like constructors).
So far rust is very nice, concise, elaborated and explicit language. Hope that the new features would be as elaborated and neat, not just monkey patches.
Template meta-programming is awful but that particular type of turing completeness isn't a problem at all. Mere arithmetic and some kind of ability to loop gives you that kind of turing completeness. The typical compiler limits looping depth to a couple hundred, and the problem is solved. Such a construct isn't a notably slow use of templates either. It's more trouble to avoid it than to have it. Compare some macros that can't loop and need a bunch of extremely repetitive lines for different sizes.
I need my typechecker be total. And you don't need turing completeness for arithmetic and recursion.
Recursion limits make it total, very easily.
> And you don't need turing completeness for arithmetic and recursion.
Yes you do. If you allow basic arithmetic to recurse n times, it can simulate n iterations of a turing machine.
I guess by modern you mean 1980, given the alternatives.