[CamTin]

Jonathan Blow (cult/indie game developer/studio owner) has a lot of ideas about evolving C++ (or rather, building a new language to replace it) specifically in a game industry context. This perspective is interesting because its kind of running at a different angle away from the "memory-safe, better guarantees" project that Rust is workin on.

https://www.youtube.com/watch?v=TH9VCN6UkyQ

Just as the scripting languages took a big bite out of C/C++ usage starting in the 90s, I think we're seeing another couple use-case for C/C++ pull off:

1) stuff that is performance sensitive but security sensitive as well (Rust) 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow's language).

Category 1 is clearly real, but Category 2 might be too small to sustain itself (though Blow makes an economic argument that it would be worth it).

Are we just going to keep peeling back C/C++ users from the pack with more specifically-useful languages until there are none left except for those maintaining legacy code? Or are there use-cases where C++ will continue to make sense?

I guess a lot of this depends on whether or not we can meaningfully "modernize" C++ through the standards process without simply bolting on a lot more features that add to the bloat. I wouldn't wager much that this trick can be pulled off.

[mattnewport]

I went back and forth over email with Jonathan Blow a while back and my opinion is that C++ is moving in a direction where it addresses most of his concerns about its suitability for game programming, though he doesn't agree. I wrote a few blog posts elaborating on why, starting with: http://blog.mattnewport.com/why-c17-is-the-new-programming-l...

I should revisit the topic in light of the latest progress with C++ and to correct some errors in those posts but I continue to believe that C++ is getting better as a language for games.

There is a somewhat legitimate argument that C++ is too complex but I don't believe you can make a convincing case that it justifies creating a whole new language (which will inevitably come with its own quirks, idiosyncracies and complexities) rather than engaging with the development of C++ itself.

[fulafel]

Given the C++ commitment to backwards compatibility, I think the case for a new language in order to reduce complexity is very straightforward. A minimal case would be a C++ subset I guess.

[mattnewport]

But the backwards compatibility is taken so seriously because it is so valuable, much more valuable in practice in my experience than the supposed benefits of creating a new incompatible language with fewer features.

[interestingcpp]

Interesting; i think it’s fairly clear by now engaging with C++ is not going to lead to reduced complexity at all. When was the last time it removed support for a feature? That’s not what the language needs because it’s more interested in preserving existing code bases than it is at improving them (the latter being a huge effort, truly massive, so i understand the decision and don’t mean it as a slight in the least).

[mattnewport]

Major influential figures in the C++ community (notably Bjarne Stroustrup and Herb Sutter) are very explicit about having a goal of simplifying everyday usage of C++ (make simple things simple). Watch any of Bjarne's talks over the last few years to see this is one of his main focuses. It's also recognized that backwards compatibility / not breaking existing code are very important however. Yes, that's a hard set of requirements to meet but I find it bizarre when I keep seeing people state that the C++ standards committee and the community in general don't care about simplicity and ease of use when those are literally the major topics of keynotes at every C++ conference of the last few years.

[mattnewport]

Complexity of the language is a much discussed topic. In the trivial sense it is true that the language will inevitably get "more complex" as new features are added but backwards compatibility is largely maintained. I don't believe that is a very relevant metric for usability however. Higher level features are generally added to languages to make them simpler to use but they also make that language more complex by some metrics. You can argue that assembly language is "simpler" than C++ because it lacks "complex" higher level abstractions but I'd rather wrote code in C++98 than assembly most of the time and I'd rather write code in C++17 than any previous version of C++ because it continues to get more usable and simple things get simpler.

[catnaroek]

Complexity doesn't come from abstraction, but rather from the lack of simultaneously short and precise descriptions of how things work. C++ isn't complex because “it's flexible enough to support several programming styles” or whatever nonsense. It's complex because its features are all bolted on, rather than parts of a coherent design from the ground up.

[mattnewport]

C++ has a standard which contains extremely precise descriptions of how things work which is more than can be said for many languages. How many other languages are there that have three major compiler and standard library implementations with almost no common code yet which all manage to be largely compatible (able to compile the same code and agree on the meaning)?

Some of the complexity of C++ comes from it doing hard things, some is in part a consequence of heroic efforts at backwards compatibility. There are areas of the language that most people stay away from or use in very constrained ways like multiple inheritance that are unlikely to be deprecated for backwards compatibility reasons but in my many years of professional C++ development multiple inheritance has never caused practical difficulties for me precisely because everybody stays away from it except for pure abstract interfaces.

[interestingcpp]

Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.

[mattnewport]

My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautologically "increasing complexity" are not interesting. Specific concerns about particular features not carrying their weight in terms of simplifying usage are interesting (and a big part of what the C++ standards process is engaged in).

[corysama]

Agreed. You have to choose between "large scale removal of features from the language" vs "30+ years of back-compat". You can't have both. A huge strength of C++ is it's legacy and the maintainers would be foolish to throw that away in a C++ 2.0 movement.

Instead, they add new features that lets new code be written in new ways without requiring you to toss out your old code. Your old C code is full of mallocs and frees. Your old code still works when you partially update it using the newest features. But, once C++ added new and delete, you rarely ever needed to type malloc or free any more unless you were overloading new and delete. Your old C++ code is full of news and deletes, but new language features added in C++11 made unique_ptr and shared_ptr possible. And, now you rarely need to type new or delete unless you are making your own unique_ptr/shared_ptr variant.

[interestingcpp]

Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary. The language complexity is still something to consider even if c++ is sufficient.

I am by no means arguing that C++ committees are making any mistakes.

[kccqzy]

C++17 removed trigraphs. C++17 removed dynamic exception specification which is deprecated since C++11. C++17 removed operator++ for bool which is deprecated since C++98. C++17 removed the “register” storage class.

[a_e_k]

C++11 removed the original meaning of "auto".

[jcelerier]

> When was the last time it removed support for a feature?

why should it ? Adding features is enough for simplifying stuff.

eg take the following code:

    for(auto& val : {1,3,12,17,20}) { val++; }

it leverages three new features: auto, range-based for, and braced initialization.

How would it look in cpp03 ? Two possibilities:

    std::vector<int> v;
    v.push_back(1); v.push_back(3); ... v.push_back(20);
    for(std::vector<int>::iterator it = v.begin(); it != v.end(); ++it) {
      (*it)++;
    }

Or

    int v[] = {1,3,12,17,20};
    for(int i = 0; i < (int)(sizeof(v)/sizeof(int)); i++) {
      v[i]++;
    }

[vvanders]

As Ex-Gamedev I don't buy that #2 is too bloated for C++, you just have to be smart about what features you pick.

Really though for what he wants to do you want a flexible framework(scripting language) backed by a fast engine(native). Jai sounds pretty interesting but I don't know if Blow has the interest in building an ecosystem around it or just using it for his own projects.

FWIW my ideal use case is Lua + Rust. I've done it on a few projects so far and really love the combo of flex + stability.

[raverbashing]

Agreed

The only case I see for "C++ is too bloated" is for embedded apps on limited hardware and even then

But then of course people make something that's 10 inheritance levels deep and (ab)uses templates and then suddenly "C++ is slow". Write better code

[AnimalMuppet]

C++ has done a pretty good job of maintaining the ideal that "you don't pay for what you don't use". Your C++ is too slow? Think carefully about which features you're using.

If you choose features appropriately (given that speed is your top concern), and you still find that another language is faster, I'd be quite surprised.

[kibwen]

I don't think this is specifically a C++ problem, I think it's a problem for any language which tries to be generalist and encompass many use cases without finding a well-defined niche. Namely, the compromises that a language makes in order to appease wildly divergent use cases will make it less than optimal at many of them, and if demand is high enough for any one of those use cases, then a different language that is custom-tailored for that use case will start to find a foothold.

I think of it like bicycling: one could use the same bike for commuting, road racing, mountain biking, and BMX, and you'd certainly save room in your garage, but most people do not need to do all four of those activities and will instead invest in bikes that make tradeoffs to excel in the use cases that they actually care about.

[mattnewport]

C++ design principles are already a good match for game development however. Specifically its intent to leave no room for a lower level language (except assembly) and to provide zero cost abstractions. There are lots of things C++ doesn't try to be and the are lots of languages more popular in particular domains as a result. C++ dominates game development (and particularly game engine development) because it is the best available match to the needs of that domain. It continues to try and evolve to match those needs better (that's why there's a game development focused study group SG14 on the standards committee, show me another language that takes the needs of game developers that seriously).

[CyberDildonics]

> 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow'

If you expect Jai to be faster than C++ I think you will end up disappointed. There isn't much reason there should be any more performance disparity than Clang and a different C++ compiler. The only language that I think could be really be called faster than C++ is ISPC.

[make3]

I'm suspicious about your so called (runtime) slow bloat. learning/understanding bloat, sure, compile time bloat, sure. But execution wise? I would like examples, specifically some that could not be dodged in a trivial manner

[steveklabnik]

From the Rust perspective, there should be no time when Rust is too “bloated” for performance. That’s clearly an ideal but if there are specifics I’d love to hear about them.

We endeavor to not ever leave performance on the table.