If C++ programmers were attracted to making their language more elegant and safe yet more powerful at the same time they would have switched to any of the statically compiled, typesafe, managed languages years ago.
If Rob Pike was doing things in C++ that Go could also solve, that means he could've done them in C# or in Haskell too, which means he shouldn't have been doing them in C++ in the first place. (Strousup explains why in his recent GN keynote if you doubt that)
Of course solving that problem by inventing a new interesting language without any of the (psychologic) baggage those other languages is awesome. It seems to be rather succeful, but it's naieve to think that it would attract C++ programmers, there's just nothing in there for them. The C++ programmers who are looking for change have more to hope for in for example Rust.
> If C++ programmers were attracted to making their language more elegant and safe yet more powerful at the same time they would have switched to any of the statically compiled, typesafe, managed languages years ago.
All of those foist garbage collection on you. Many of them find text-based macros such as C++'s template engine morally offensive and so they don't include that feature.
If you want a statically-typed Python, then Scala and C# and the like will serve your needs nicely.
If you want a modernized C++... it still doesn't exist. Rust looks promising, but that's not exactly mature technology.
Haskell's lambdas are extremely elegant (\args... -> code, and treated no differently to any other function), but C++ has a pile of other considerations that Haskell doesn't have to worry about, due to Haskell's uniform representation and garbage collection.
I think that functions and closures are fundamentally different types. Haskell does implicit type erasure whereas C++ does not. Most of the time in C++ when you use lambda you don't need uniformity and you are better off using templates to pass them around. For the rare circumstances you do need this, you just stick it in a std::function. Haskell also has mechanisms that could handle this: type classes/parametric polymorphism/existential types and I would find this a much cleaner approach, but it would wreak havoc with other design decisions in the language such as currying. My main point of this is that Haskell proponents often think of C++ programmers to be unenlightened or wilfully ignorant, when its actually very possible they have thought things out and simply reached different conclusions.
If Rob Pike was doing things in C++ that Go could also solve, that means he could've done them in C# or in Haskell too, which means he shouldn't have been doing them in C++ in the first place. (Strousup explains why in his recent GN keynote if you doubt that)
Of course solving that problem by inventing a new interesting language without any of the (psychologic) baggage those other languages is awesome. It seems to be rather succeful, but it's naieve to think that it would attract C++ programmers, there's just nothing in there for them. The C++ programmers who are looking for change have more to hope for in for example Rust.