A major chunk of software developers use C/C++ (including a lot of Game Developers); Although lot of people see only the tip of the iceberg. Look into your systems. Almost everything down there from your database to your compiler/interpreter/VM to your operating system, your web browser, your music player, the internals of your search engine and yes your favorite games (renderer, physics, most of the gameplay) is probably being developed and maintained in C/C++.

The reason for C++ being used is not only Performance, but also a sense reliability that the implementation will actually work.

I like C++, but I am also quite older than the language and remember when the language was seen as unsuitable to write any of those systems you have mentioned.

Eventually it got adopted by people like myself that didn't care for the naysayers and its compilers improved to the point many think it was always like that.

Likewise others will use languages that the naysayers of today won't see as proper to write them and in ca 20 years from now, everyone will think they were always that way.

In the early 90's I posted on some game developers forum that when consoles got more powerful processors it would be possible to write games in C instead of using assembly language. Everybody told me that I was an idiot.

You are right. I see a huge potential in Rust. It seems very suitable for the C++ level domains. The only thing keeping me away from production usage today is the lack maturity with ecosystem and libraries.

Rust is kinda the Godwin's law of C++ threads these days.

C++ is huge in scientific programming. Fortran is the cliche language for science, but the vast majority of newer large-scale codes are being written in C++.

AFAIK Debian isn't very diligent about tagging packages with "implemented-in", but even so:

  dpkg -l |grep ^ii -c #Installed packages
  3608
  # packages tagged as being in c++, and installed:
  aptitude search '?tag(implemented-in::c++)' \
    |grep ^i -c
  930

I'm sure there's lots of c++ in the other 75% (or they depend on a runtime/compiler/library written in c++) -- but at any rate - one in four packages is nothing to sneeze at.

Your search query needs escaping for the pluses, otherwise it will match 'implemented-in::c' as well (aptitude's matching is weird).

Whoops, you're absolutely right. Eg:

  '?tag(implemented-in:c\+\+)'

On a different desktop right now, so can't check -- but that'll probably lower the count considerably (eg: on a different server I get 226 for "c/c++" and 19 for just "c++" ("c\+\+)").

Linux is more of a C than a C++ land, so the figure does not look unreasonable to me.

This is completely irrelevant to the question. Furthermore, most of the code was written a decade ago. Why can't I use Go, for example?

At PlexChat[1], we intend on using C++ to write a lot of our infrastructure (where it makes sense, that is). The language has advanced significantly in the last decade and writing idiomatically correct, and safe code, is much easier than it used to be.[2]

Garbage collection is certainly a part of it, but really, it's about programming with a deterministic runtime. Controlling memory budgets and doing things described in this talk is possible in an environment where the programmer has control, but instrumenting a blackbox runtime to identify performance bottlenecks and pain-points can be a huge endeavor. Other languages optimize understandability of the programming semantics (what is this algorithm doing) but do very little to aid in expressing runtime semantics (how will this algorithm execute on the machine).

[1] http://plexchat.com [2] https://www.jetbrains.com/cpp-today-oreilly/books/Cplusplus_...

> Other languages optimize understandability of the programming semantics (what is this algorithm doing) but do very little to aid in expressing runtime semantics (how will this algorithm execute on the machine).

I think this is painting other languages that aren't C++ with too wide a brush. There are many non-C++ languages that make it "easy" to control the low-level generated code (though I question really how easy it is with how incredibly aggressive in optimization modern C++ compilers are).

Other languages, not all other languages ^^. Yes of course there are several languages that map more directly to one's mental model of how code is executed. Rust (which you're working on) is an one such exception. Optimizations are certainly aggressive but the micro-optimizations are usually either well known (like NRVO, loop unrolling, function inlining), or not important relative to more costly operations that are occurring (allocations of heap memory, fetching from the heap, executing a system call, acquiring a mutex, etc).

C++ isn't the only language that offers such garanties.

What it is, is the 90's survivor of all wannabe C replacements.

I can answer only for my own account, but for starting a new project in late 2013 december, and now been working for it the past two years, related to custom geometry generated in VR, C++ was the only viable crossplatform option.

With C++ (using the C++11 standard) I can assure pretty sure that the code compiles on Mac, Linux, Windows, Android, iOS and pretty much every platform.

With the VR -platform we also need all the performance we can get, because target FPS is 90 on a stereo rendering sized area.

Also, library support, existing code to use and so on all win here.

Definitely C++ is not the most nice language to get into, Objective-C for example is much nicer IMO. But the more you use C++, the more nicer it gets as you learn the ropes more and more. It's a very complex language, but knowing it pays off in the long run, and the modern C++11 and C++14 are a completely different beast than the previous implementations in terms of ease of usage and code syntax niceness.

So, crossplatform is a big thing. If I would write it in C#, it would be tied to either Microsofts C# or the Mono implementation. If I would have chosen Obj-C, it would be pretty much Mac and iOS only.

When you need performance + crossplatform, C++ just wins.

However that is a consequence of available implementations, not of the language itself.

Back in the day, I went Turbo Pascal -> C++ exactly for that reason (Turbo Pascal -> C was never an option).

If the UNIX systems I had to work with, had a Turbo Pascal compatible compiler, I would kept using it.

Well, partly yes. If this was year 2030 and Rust was available on every platform so that everything worked perfectly, I would have probably used that.

Desktop applications requiring high performance also use C++. Photoshop (and perhaps many parts of the Adobe suite?), and Tableau come to mind.

Your intuition about gc pauses is correct, when you have to push frames every 15-30 miliseconds, you can't afford any kind of unexpected pausing. Game devs also use a huge number of hacks to hit their performance targets, something that using c/c++ makes much easier due to their relative looseness.

No, C/C++ is still very commonly used in many real time systems, embedded systems etc. But, since most of the topics in HN are in the web/android/ios areas, you might not see many devs talking about it here. C/C++ (esp on linux/RTOS) still has a very active user base and market demand !

C++ is still very heavily used in industries where speed (and memory compactness) matter. Games, simulation, VFX...

For example, most software used to make film movies / CG imagery: from modelling (Maya, SI), to texturing (Mari), to rendering (PRMan, Arnold, VRay, Mantra, Hyperion, Manuka), to compositing (Nuke).

And it probably will be for many years to come as there's such an infrastructure there.

It's quite likely that C++ code rendered this web page for you. If you're on a Mac, that code was itself likely compiled using C++ code.

Or on Linux or Windows: gcc is now written in C++, and I'm pretty sure MSVC itself is in C++.

Yes, both MSVC's front-end C1XX and back-end C2 (aka UTC) are written in C++. Even our CRT is mostly C++ now.

Do you update it to follow the latest standards or is it early 2003-ish C++?

C1XX uses new features fairly aggressively. For example, it uses lambdas, auto, range-for, etc.

Too bad nobody directly addressed your question as to whether it had anything to do with pauses which would be unbearable on the gamer's experience.

Perhaps the question is still open whether properly managing allocation, using object pools as well as other strategies would enable writing triple A games with a managed language.

Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.

It's not that you couldn't write a triple A game with a managed language.

It's that you can _quite easily_ write a triple A game without using a managed language.

For games, managing memory is not a big problem. For other kinds of apps, it can be. In some apps the lifetime of an object is not well defined. But in games, it tends to be very well defined.

If you want a good explanation of the problems game developers face when trying to use GC, go read Rich Geldreich's post on it (http://richg42.blogspot.com/2015/05/lessons-learned-while-fi...).

There some AA or AAA games using languages that not are C/C++ . Severence: Blade of Darkness (Aka Blade: The edge of darkness), have a lot of code on pure Python. And it's well know that Naughty Dog use a variant of Lisp on his games.

I'm sure there are - that's not what I said.

Also, Naughty Dog's games do _not_ use Lisp, they use a custom language that looks a little like Lisp, but has no garbage collector.

Naughty dog used to use Game Oriented Assembly Lisp (GOAL), which was very scheme like. They dropped it for C++. Although they still use a Racket dialect for some gameplay scripting.

Lisps without GC have been used in various places for delivery.

An example was Thinlisp, which tries to be mostly compatible with Common Lisp, but without GC. The compiler for Thinlisp is written in Common Lisp.

G2's Gensym is written in such a Lisp. Thinlisp also comes from them, IIRC. http://www.gensym.com

Some Lisp don't/didn't use a GC, but reference counting or similar schemes.

See my comment below, GC isn't the problem. It's being able to layout your memory appropriately so you don't cache miss which when everything is a single heap allocation becomes almost impossible.

> Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.

This has been happening for a long time with Java HotSpot and Azul C4, which still represent the state of the art. Go isn't really doing anything new—it's still not generational, for example.

The speed of the GC isn't the issue (although it certainly can be). The non-determinism is. It's hard to control when a GC should happen, and when it happens at a bad time, the ramifications are perceived as an awful user-experience.

It's not garbage collection(although that's a part of it, but Unreal3 actually had a GC).

It has to do with memory layout. Cache misses = lost performance and being able to structure your memory appropriately is super-important. Look up Mike Acton or any of the Data Oriented Design stuff for more details.

Many, if not most desktop applications are written in C++. Just because you don't use it doesn't mean anyone else doesn't.

> I imagine game developers are the few people left using C++. Does this come down to not being able to get around pauses in garbage collection?

That is one reason. But if you watch OP's video, you'll see a lot of other reasons. In particular, games frequently have their own allocators & memory management. This is one reason why it might be hard, inconvenient, or impossible to use Java or C#.

That said, a lot of gameplay logic these days is actually written in a scripting language like Lua, and C++ is used for lower level systems like rendering & physics.

> In 2015, starting from scratch, where is C++ needed?

The main question is: "starting what"? For most web dev, you'd be crazy to start with C++. For the internals of a game engine, like unreal or unity or a competitor, C++ is probably the only sane choice. Also anything embedded. I guess Arduino & others are getting interpreters now, but C/C++ (notably minus the crazy kind of stuff in the video) is the easiest way to start.

I used to do hobby projects in C++, mainly graphics & image processing. My reasons were I knew it, it compiled to very fast code compared to anything else, and it was often the easiest way to interface with whatever open source libraries I needed.

These days most libraries are available in your favorite scripting language, and the performance can be good if you pay attention. I don't personally have a reason to use C++ anymore, even for hobby projects that need high performance.

I use a fair amount of C++ for my code and its entirely because all the other tools I use - SAT solvers, model checkers, etc. are written in C++. I don't like it very much and many others in my community don't like either, but we're all stuck in this local maximum.

Moving to an entirely new language is impractical for any single project so all the new projects end up using C++ which in turn means the projects that come after them ending up using C++ as well. For a concrete example, look at something like ABC (https://bitbucket.org/alanmi/abc). There is very little incentive to rewrite the whole thing in a safe language but if you're doing new circuit verification research having ABC's humongous library of transformations and verification algorithms will be a huge help in implementing new things.

There have been a few attempts to break away though. Some folks at SRI wrote the model checker SAL in Ocaml, a lot of CMU folks seem to like Ocaml too: for example the bitblaze project uses Ocaml. And z3py has helped make Python popular.

I've lost countless hours of my life debugging the sorts of issues this guy is talking about, so I really hope we do make the switch to something better.

I use C++ in my work - robotics/Comp-vision. We need it for the performance and the cross-platform characteristics. It is a highly powerful language once you get used to its complexity. In my experience, it is the most popular language in the robotics community, though not for prototyping (Matlab, python are more common for prototyping)

Here's Tim Sweeney of Unreal fame talking about GC: http://lambda-the-ultimate.org/node/1277#comment-14252 (granted, it's from 2006, but I still think it's relevant)

TL;DR: It's not a problem.

Check out this talk by Herb Sutter https://sec.ch9.ms/ch9/ddaf/d4642f30-491c-481d-97c5-62aa5ab6...

yeah, few people left using C++ ...

Such naivety.