I don't agree that growing a language necessarily makes it harder to learn. Quite the opposite, I think it makes it easier to learn. Look at how asynchronous c

I don't agree that growing a language necessarily makes it harder to learn. Quite the opposite, I think it makes it easier to learn. Look at how asynchronous code was handled in C# in the past versus today. In the past, you first had to define a delegate type for the signature of the procedure you wanted to run. Then you'd assign something to that delegate, probably a method sitting in a class somewhere. You can now call BeginInvoke on that reference, passing in a callback function. That callback function has to be another method sitting in a class somewhere. You also get this IAsyncResult object returned, with no immediate guidance as to what it's supposed to do. Is it different than the IAsyncResult that gets passed to the callback? No? There's this "AsyncState" object you're supposed to pass, with no clue what it's meant for. If you don't need it, you pass null, which is pretty much every case. Need to return a value? Call EndInvoke with the IAsyncResult object you received in the callback. But wait, where's my delegate instance on which I need to call EndInvoke? Guess I need to hoist it to be a field in my class now. I suppose you could pass it as that AsyncState parameter, but now you're having to do in your head the type-checking job that the compiler should be doing for you. None of this is guessable from just reading the code. You have to read the documentation in multiple places to figure out what is going on. For added fun, now try composing multiple async operations in sequence. Contrast to today, we do "Task.Run(<some lambda expression>)". You tell me what is easier to learn? You see "fewer keywords, fewer features" and see "simplicity". I see those things and I see "more boilerplate for implementing code" > "complexity".