The C++ bashing season is back (2009)

http://eli.thegreenplace.net/2009/10/17/the-c-bashing-season-is-back

by luu • 11 years ago

40 95 11 years ago

eli.thegreenplace.net

beefhash• 11 years ago

I wasn't aware the C++ bashing season had ever stopped. Did I miss something?

wyager• 11 years ago

µTorrent is written in C++, and you could never, ever, make it so fast and small using any other language.

That is not a reasonable claim.

The article mentions C, but there are a number of languages that could ostensibly produce a binary of a similar size and efficiency. Rust comes to mind.

pdpi• 11 years ago

Rust was announced in 2010, post is from 2009.

quonn• 11 years ago

True, but at the time of writing, Rust was not available, yet. Can you think of another language? Much of the excitement for Rust comes because it really is the first language that tries to beat C++ (and C) at it's own game.

pjmlp13• 11 years ago

Delphi, Modula-2, Oberon, Component Pascal?

All strong in the 90's, sadly the market went somewhere else.

Only Ada seems to survive, but in its own area, high integrity computing.

deeviant• 11 years ago

Yes, without C++, µTorrent could never have packed so many annoying "meet random super models and have sex!" ads into the ap. It just would have been impossible with something like java.

flamedoge• 11 years ago

This calls for science!

panzagl• 11 years ago

Article is from 2009. I was wondering if this was a reaction from the vaguely positive press C++11 and C++14 were getting lately, but it's not.

somerandomone• 11 years ago

But for some kinds of applications it seems that the only viable options are still C and C++ ... and you could never, ever, make it so fast and small using any other language. C++ and C are the only options you have here.

Is Go a viable alternative now?

rjammala• 11 years ago

I think once the garbage collector improves with the 1.5 release, it will be a serious competitor.

voidlogic2• 11 years ago

Most Go apps can get better than advanced Java GC level allocation-memory performance simply by applying "sync.Pool" (http://golang.org/pkg/sync/#Pool) on applicable pain points.

Its also worth mentioning using a custom allocator + mmap is possible in Go if you really needed it.

Go is also better than Java about using stack allocation for objects.

microtonal• 11 years ago

Another weak point of Go for high-performance computing (besides the garbage collector, which is indeed making huge strides), is the compiler.

Modern C++ compilers do auto-vectorization, offer OpenMP, etc. Of course, you can work around this by writing your numerical code in C or C++, let your C/C++ compiler do the work and bind from cgo.

Another shortcoming of Go is that it cannot be used for building non-Go libraries. First of all because the defacto compiler cannot create shared libraries, secondly, because having a garbage collector gives ownership difficulties once you start binding against another language with a garbage collector.

I will not repeat the usual generics stuff, except that lots of optimizations in C++ code rely on generics (e.g. algorithm selection based on the data type or data type properties).

(No, I am not starting Go bashing season ;), I like Go a lot and it can be used to replace C++ in many projects. Just stating the weak points when coming from C++.)

bhouston• 11 years ago

Go and Rust may be alternatives theoretically, but can you create rich cross platform GUI applications that utilize OpenGL or other fast drawing libraries with either?

That is one of the primary domains of C++ - e.g. photoshop and similar tools.

Go seemed more oriented towards server programming.

RussianCow• 11 years ago

This is totally possible in Rust. The biggest problem with Rust is its immaturity, but give it a few years and it'll be a contender for these types of applications. I can't speak for Go.

jerf3• 11 years ago

For the "some kinds" of applications implicitly under discussion, the ones where even in 2009 you'd be looking at C or C++ because, say, Python simply would not do at all, no. It IMHO has a really compelling bang-for-the-buck on the ease-of-use vs. performance, but it is not 100% tilted towards the performance or control side, which makes it unsuitable when you really need those thing. I think it's taking off because it has substance and not just hype, but look at all the "we switched to Go and we love it" posts and you'll see a pattern; they're mostly right in the domain that Go was basically written for, scalable network servers.

The thing that may replace C and C++ right in the niches that are keeping those now-ancient languages current is probably Rust. If successful, Rust will grow beyond that, but it's the only thing squarely pointed at C and C++ right now that seems to have the momentum behind it. Though if you want something right now, you can also try D.

yaur• 11 years ago

I'm working on a media library at the moment and it doesn't look like it would be an option. The main reasons.

  *GC is a non-starter. An HD frame buffer is around 3MB, a 4K buffer is around 13MB.  Letting a GC manage your buffers will lead to heap fragmentation and bring down 32-bit builds relatively quickly.
  *Similarly you don't want to copy these things unless you have to so a strategy where each filter is responsible for its own buffers will result in roughly a 3x factor in memory bandwidth.
  *All of the downstream software is written in C. So just to get it into GO I either need to do another memcpy or use unsafe stuff in order to deal with it nativly in Go.  This along with the above means that I would be looking at 2GB/s of memory bandwidth per stream instead of 500MB/s for a 4K stream.
  *My upstream targets include software written in Python and C#.  Go appears to assume that it owns main, which is obviously a problem.

jerf3• 11 years ago

Go can pass around byte buffers without copying them... a core use case for its core functionality as a network server. The real problem you'd hit with frame processing in Go is that it doesn't give you access to SIMD, nor does it have a nice GPU connection for computation.

I like Go, but I don't really consider myself an "advocate", and part of that is not overpromising to people. If you've got really heavy-duty computational needs, like in science or graphics, it's a bad choice right now, and I expect it to remain so for the forseeable future because it's not a core concern of the devs, and I'm pretty sure they'd view it as dilution of their goals and value proposition. (Correctly, I might add.)

bryanlarsen2• 11 years ago

If C and C++ were the only options, then Go is probably not a viable alternative.

Reasons why C and C++ are the only options might include:

- small executable size. Hello world in Go is over a megabyte

- real-time without GC pauses

- first class native bindings to a certain third party library

That being said, Go is certainly taking market share from applications that traditionally would be written in C/C++. Take Docker, for example. It theoretically could be written in any language that can do networking and Linux syscalls, but pre-golang C or C++ probably would have been the best choice.

I personally see Go as more of a Java killer than a C++ alternative.

unscaled2• 11 years ago

Go isn't (and probably will never be) a viable alternative for most of the use cases where you'd want C/C++:

1. Embedded, real-time, kernel: As a GC language which is not meant to write close-to-the-metal code and produces rather bloated binaries (especially compared to C), Go has no chance here. This trinity is still very much the sole territory of C where even C++ seldom dares to tread.

2. Truly cross-platform (not just Windows/Linux/Mac) performance-sensitive libraries that need to be callable (using bindings) from a wide range of programming languages (including C). This is a very common but often neglected class of software where C/C++ reign supreme. Libraries need lots of flexibility in terms of ABI support (e.g. support linking with different C stdlibs) and deployment (e.g. dynamic libraries, which Go, AFAIK, still doesn't support).

3. Complex and lightweight GUI apps with high performance: This is the main class of application mentioned in the blog post. While there are some Go bindings to popular GUI libraries such as Qt and GTK, I'm not sure if their mature enough. Using Qt directly from C++ still seems like the path of least resistance to me. As for lightweight apps, Go apparently still has some work to do about the binary sizes.

4. Web Servers: This is where Go should shine! Programming a concurrent web server using Goroutines should be a breeze, and considering most web servers are still written in C, we would be relieved of the nightmare that is string manipulation in C. But right now, there's still doesn't seem to be any Go equivalent of nginx in development. Go is probably getting mature enough, but I think that if actually squeezing every last ounce of performance is your goal, it still can't beat nginx. For instance, nginx employs many tricks to optimize its memory allocation pattern specifically for the task it was meant to do, and I find it hard to believe that any one size fits all GC, no matter how intelligent, can get the same performance.

jerf3• 11 years ago

" But right now, there's still doesn't seem to be any Go equivalent of nginx in development. Go is probably getting mature enough, but I think that if actually squeezing every last ounce of performance is your goal, it still can't beat nginx."

There's no nginx in development because the built-in net/http library is actually pretty close to it already. Nginx beats it, but only by something like 25-50%, and if you compare the nginx source code to the net/http source code you'll see why nginx is going to likely retain that lead and Go isn't interested in the code quality tradeoff it would take to catch up to nginx. If you ever need an example of C used as "portable assembler", cite the core loop code of nginx.

api4• 11 years ago

I'll keep saying it: give me a modern language that is cross platform, results in reasonably sized code footprints, is fast, and that can be used to ship code on all the major OSes, and I'll switch. Until then C/C++ is the only way to achieve that.

It's analogous to the situation with JavaScript on the web. JavaScript is the language of the web because JavaScript is the language of the web. C/C++ is the language of systems because C/C++ is the language of systems.

evincarofautumn• 11 years ago

Rust is getting there. In addition, I and I’m sure many others are working on languages with these goals.

Scramblejams2• 11 years ago

Besides the aforementioned Rust, I think Nim's got a lot of potential here. And although I'm not a fan, does Go not fit the bill for you? Of the three languages I mentioned, it's the only one that everyone agrees is production ready.

plq• 11 years ago

Nim's got a long way to go with its thread-local non-shareable heap if it's aiming to replace C++. (I don't think it actually does.)

jayvanguard6• 11 years ago

Don't mix the two together. C is great for systems and some application programming, C++ is rubbish.

There was one brief stretch in history around 1994-1998 where C++ was the best choice for application level programming. And even then only a very narrow type of app programming.

Before that brief timeframe and since then it has been a poor choice for every single type of programming. There are better choices in all cases. It has no niche anymore where it is the best fit, not anywhere.

pjmlp13• 11 years ago

C++ lets me write safe code, C on the other hand....

CountSessine6• 11 years ago

Before that brief timeframe and since then it has been a poor choice for every single type of programming. There are better choices in all cases.

For memory-sensitive applications where time-amortization hurts (and this turns out to be pretty much every application that anyone wants to run on their local computer), C++ is still king and is still the best choice for the job. Everyone hates C++, and yet every desktop application in widespread use is built with it. I wonder why? Is it really just inertia?

Java, C# - programmers are stuck with a runtime that literally consumes 10x ram as equivalent C++ software. Do you like switching applications on your Android phone and having every other process pushed out of memory? I didn't think so. And while both environments are now offering ahead-of-time compilation, the CLR/JVM runtimes are still much larger than what C++ consumes and you give up the only chance of matching C++'s runtime CPU performance (harvesting runtime profiling to inform the JIT).

Golang - a huge step in the right direction, this will probably end C++ use on servers and hosts eventually. It still can't match C++'s runtime performance, but who cares in a host environment. Still, garbage collection makes it unsuitable for local applications where users notice micro-pauses due to garbage collection. Nothing is worse than going into alpha with 10 P0 bugs complaining about 'micro-pauses' and finding out it's because of something you can't change in the runtime.

D - truly a better C++ than C++. But no one uses it.

Rust - our best hope so far, but the compiler and standard library aren't there yet. You still can't program a web server, for example, without manually handling unsafe objects. Even then its going to be years before there are libraries available that are of similar quality to things like Qt. How do make a GUI application in Rust in 2015?

C - I hope you like (void*) and all of the fun runtime bugs that introduces.

But seriously - "There are better choices in all cases"? Like what?

aurelius• 11 years ago

1994-1998 was a bad time for C++. Stepanov had just come along with the STL idea, and there were various competing implementations of it. And I don't think I need to say anything more about the travesty of MFC other than to acknowledge its mere existence.

C++14 (the latest standard) is a far better language than C++ in the '90s, and it really does beat C when it comes to abstraction capabilities, type safety, and standard library functionality. C++11 also defined a standardized memory model which is extremely useful for writing multithreaded code.

Yes, C++ is not perfect -- the C++ standard library lacks a lot of functionality found in the libraries of other languages; there is a lot of complexity in the language that one must master to really "know" C++; the language itself has dark corners and disappointments; and so on. No language is perfect, and every language permits bad code.

I've been working with C++ full-time for the past three years. I didn't know much about the language before then (I was a "C 43var!" guy), but had heard all the horror stories about it. Now, I'm convinced that it's probably the best general purpose programming language available to date. It combines the full power of the machine with very expressive abstraction capabilities. Having seen what can be done with C++, I decided to study harder and try to master it.

I think this last point is ultimately what puts people off, and leads to a lot of FUD about C++ -- it takes hard work to master the language and the tools to work with it. Nobody really wants to do that, not when there are seemingly viable, and easier, alternatives. Instead, people are more willing to invest huge amounts of effort and money to try to scale up those alternatives if it means they can avoid the complexity of a language like C++. That's fine, I guess, we all have to make the appropriate engineering trade-offs, it's just unfortunate that many people fall into extremism about it in order to justify their attempt to simplify the reality of computing (which is actually considerably complex).

loqi• 11 years ago

C is great for systems and some application programming, C++ is rubbish

This is a bizarre claim. C++ has its problems, but the fact that it allows zero-overhead abstractions over common low-level boilerplate is a seriously non-trivial advantage over C in most areas where C is otherwise a good fit. What compelling advantage does C retain over C++? Faster compiles and being easier to learn are nice and all, but hardly slam-dunks.

eliben3• 11 years ago

Mercy, folks, this post will turn 6 years old soon. Let me know if you have any questions (or just leave a comment).

smhenderson• 11 years ago

Still a great read though and, with the recent release of new standards for C++, still relevant today.

Thanks for sharing...

mbrubeck• 11 years ago

Isn't it already over five years old?

eliben3• 11 years ago

Oops, thanks. Math is hard :) Fixed

xjia2• 11 years ago

If server-side (web)apps were written in C++ instead of Ruby/Python/..., I believe they can sustain much more users before they need to consider horizontal scalability seriously, since we can fully utilize the machine in C++. AFAICT it is nearly impossible to optimize to the level of cache efficiency (and etc.) in Ruby/Python/..., and a distributed system is much harder to cope with, and when you need to work on that, the choice of programming language becomes less important.

However, building a not-so-bad prototype in Ruby/Python/... is much easier. So probably something needs to be done (e.g. "frameworks", libraries, tutorials) for C++.

[EDIT] C++ (templates) can provide abstractions with zero run-time cost. C doesn't have such abstractions. Ruby/Python/... don't have such low cost.

jayvanguard6• 11 years ago

But most (or at least a huge percentage of) server-side web apps are written in Java. While I don't love Java it is better in every way shape and form for server-side web apps than C++.

xjia2• 11 years ago

That's probably due to the lack of resources (as I mentioned, libraries, tutorials, etc.) for programming server-side webapps in C++.

However, this could be a chicken and egg problem. People use Java more often so they produce more resources.

pjmlp13• 11 years ago

True, but early C++ libraries were tainted with a C mindset so althouth C++ could provide a Java like confort, you were stuck with C with classes libraries instead.

Just look at MFC vs OWL vs VCL, or Visual C++ vs C++ Builder.

CountSessine6• 11 years ago

This really seems like the sweet-spot for Go - nearly the same runtime performance as C/C++, and no single-threaded memory leaks or stomps. Low memory overhead, fast startup time, and the time amortization inherent in garbage collection doesn't matter a whit.

Animats5• 11 years ago

Now is a good time to bash C++. The alternatives are better than they were in 2009. For web stuff, Go is a good alternative. Rust is starting to look like a good alternative for low-level code.

The C++ crowd keeps trying to paper over the Mess Inside with templates, but the mold keeps coming through the wallpaper. After dealing with C++ since the mid-1990s, it's time to move on.

There have been good alternatives over the years, but their backing companies failed for other reasons. Xerox had Mesa and Cedar. DEC had Modula 3. Borland had Delphi. None went mainstream outside their niches.

Today, a compiler almost has negative commercial value. It took $20 million to launch Java, and the compiler was given away. The Go and Rust compilers are free. There was a time when a C or C++ compiler cost several hundred dollars. Now, you have to give them away. It's hard to fund development in that environment.

eliben3• 11 years ago

I have to admit I fail to see the point you're trying to make with the price of the compiler; how does this bear negatively on the C++ language?

pjmlp13• 11 years ago

You need to be able to provide a compiler for your language that can beat C++ compilers, while offering for free, because in 2015 almost no one pays for compilers.

So without a strong revenue, it is almost impossible to provide alternatives, hence the status quo doesn't change.

bryanlarsen2• 11 years ago

The reason that compilers are free is because they are complements in economic terms. Having good compilers available for free makes CPUs more valuable, that's why Intel & Apple invest millions of dollars every year into compilers. Good compilers make software more valuable, that's why Google, Apple and Mozilla invest millions.

But you're right: compilers almost have negative commercial value. So many deep pockets are spending so much and giving away the results, making it hard to compete.

weland• 11 years ago

It's worth noting though that part of Go's toolchain is based on that in Plan 9, which was well-funded at one point.

static_noise• 11 years ago

You can bash C++ all you want yet it is the one language that stands in the middle of high performance and systems development. Somehow all the "alternatives" fail in some part and all you're left with is C++. Rust may be getting there but it will take years until you will program your embedded realtime application in it.

pjmlp13• 11 years ago

It wasn't always like that though.

C++ got into this position due to people like me, that were considered hipster back then, by going with that slow molass, full of portability issues trying to implement parts of C++ARM, instead of C.

I did it, because sadly the vendors of the alternatives mentioned by Animats didn't managed to keep their languages up to what the OS vendors were putting on their SDKs.

So stuck between C and C++, at least C++ was already a better alternative than writing plain unsafe C code.

tdees40• 11 years ago

I'd make the argument that Rust is making many of the same mistakes as C++. It's got a kitchen-sink approach that has already accumulated some barnacles, and that ownership system is a mess.

Animats5• 11 years ago

The ownership system, the big innovation in Rust, isn't bad. The type system, macro system, and error handling interact to form a big mess. Exceptions would have been simpler than the mechanisms used to avoid exceptions.

kibwen2• 11 years ago

If you think that Rust is a kitchen sink language or that the ownership system is a mess, then I have to assume that you have neither followed the language through its development nor used it. It catches flak every day for not being a kitchen sink language, and the ownership system is probably the only part of it that's so finely-polished that I have no faults with it.

Now, Rust macros? Those are gross. The module system is love-it-or-hate-it. The syntax could be most charitably described as "classical" and the compiler itself is held together with reams of duct tape. But it's the first language that's attempting to explore this design space in an industrial setting and encounter all the problems therein (for god's sake, they had to reinvent the notion of closures (and even if you superficially believe they're similar to C++11 closures, the mechanisms required to make C++-style closures memory-safe are novel AFAICT)). Despite all of its flaws (and the upcoming 1.0-stable release will have flaws), it's a remarkably worthwhile language to learn and will influence every language to come that cares to call itself a systems programming language, all because the core ownership system has been so long iterated-upon (and even that will continue to see ergonomic improvements as time goes on).

IshKebab• 11 years ago

The kitchen sink approach is why C++ is still so popular. I'm glad Rust is multi-paradigm.

edwinnathaniel• 11 years ago

For web stuff I'd say Java is a better match :D

joe_the_user• 11 years ago

I'm putting together an app where the c++ code is more or less adding a structure over "raw bytes" in memory or on disk. I actually looked at Rust but I can't see how it would help when you want to have all you operations really be a big chunk of already allocated memory.

c++ isn't going to be growing because it's less applicable to the new use cases but I don't think that makes it less applicable to standard use cases.

jkot• 11 years ago

I am former Java maintenance programmer and I hate C++ with passion for over decade.

But I recently started KDevelop IDE and was very surprised how nice is C++ with QT lib. I am even considering to join an C++ opensource project.

nicolasp• 11 years ago

You should give QtCreator [1] a try. It's made by the Qt people for Qt development, but even for non-Qt stuff it's a pretty good IDE.

[1] http://qt-project.org/wiki/Category:Tools::QtCreator

cowardlydragon• 11 years ago

The FQA specifically mentions how nice QT is, about the only positive comment on C++ in the entire thing.

ericfrederich• 11 years ago

I'd like a fresh perspective on this taking at least C++11 into account, perhaps C++14.

Doji• 11 years ago

C++11 and C++14 make the language bigger, which doesn't address the problem of the language being too big.

nether• 11 years ago

Will we ever see a AAA video game title written in anything else?

pjmlp13• 11 years ago

C++ wasn't always there.

kibwen2• 11 years ago

It depends on how you define "AAA". Any big-name game written before the mid-to-late-90s (Mario, Tetris, etc.) wouldn't have been written in C++. Mobile games (Angry Birds, Candy Crush, etc.) cannot be written in C++ by dint of their platforms. Minecraft, a contender for the best-selling game of all time, is written in Java.

FigBug2• 11 years ago

Angry Birds most likely was written (at least partially) in C++ as Rovio has confirmed that they used Box2D, a C++ physics engine, as the engine for Angry Birds.

All the major mobile platforms support C++. Android through the use of the NDK. Windows phone has support C++ since version 8. iOS has supported C++ as long as there has been the app store, either through Objective-C++ or C++ libraries with a C interface.

a8da6b0c91d• 11 years ago

I think people miss the context and subtleties of the Linus Torvalds rants. He was addressing rather idiotic junk on the mailing list about using C++ in the Linux kernel. He was trying to shut down some spergs who wouldn't grasp a more subtle request to not barge in on a decade plus old team of C hackers with tooling discussions.

In other forums he has praised Qt and uses it.

ksk• 11 years ago

C++ is a language designed for specific use cases. If you want a systems level language with extremely low cost abstractions and write high performance, or low service-latency applications or applications that run on devices where you care about power consumption, memory utilized, etc, then C++ is one of the languages that you could consider.

Its pretty bizarre to compare it to python or ruby or perl. Yes, you should use other languages if you can. C++ is used when you cant.

The C++ bashing season is back (2009)

Related Stories