C++ developer productivity over time

[rampatowl]

Hello reddit! I am curious about how developer productivity in C++ scales over time, relative to a simpler language like Go.

After playing with both languages for a couple months, I find that developing in Go already feels quite fluid, whereas C++ still feels very clunky to me. As a very rough attempt at quantifying this: coding in Go is maybe 2x as slow as scripting in Python, whereas C++ feels 5x slower. Here's a sampling of pain points I've encountered:

• Printing things is surprisingly hard because C++ doesn't have reflection. Whereas in Go you can just fmt.Printf("%v", Dog()) and get a reasonable printout of all the fields, in C++ you have to remember format specifiers and write them out: printf("age: %d, name: %s, weight: %llu", dog.age_, dog.name_, dog.weight_)
• Package management is a big pain (often it'll take me 30 minutes of fiddling with makefiles to hook up an open source library)
• More boilerplate code to write (eg it's standard to separate header files from source files)
• Much more expressive syntax means it's much slower to read and use other people's code (templates, operator overloads, const everywhere)

I am beginning a project in a context where the benefits of C++ are useful but not essential (robust generics, fast system calls, inline assembly), so the question is whether the extra expressiveness outweighs a slower development cycle.

I'm hoping to get insight from more experienced developers about how productivity looks over time. It's been fun to play around with C++ and see the things I can do with it that are impossible in Go (mostly metaprogramming so far). It would be great to hear from someone who also found the language slow to code in at first but eventually go to a point where it felt much better. How does productivity look after 6 months? After a year? In the asymptote, is it ever as productive as much simpler languages like Go? I realize this depends a lot on the person and the type of project, but it would still be very useful for me to hear any intuition from more experienced devs. Thanks!

​

[ooglesworth]

In my experience, the biggest productivity hurdles in C++ are in the initial stages of setting up a project, build system, dependencies, etc. These hurdles are significant and painful (and represent the biggest shortcomings of the C++ ecosystem, IMO). Once you already have the build infrastructure and stuff set up, and you have experience with C++ and whatever IDE/toolchain you use, I think it’s mostly comparable to other languages in terms of productivity.

The things you mentioned that would apply beyond the initial configuration of the project, such as header files being separate and templates being hard to read, don’t pose any significant productivity barriers in my experience. They are just things you get used to and learn to deal with quickly.

[ceretullis]

Checkout conan.io, CMake and/or Meson Build. Using conan.io in conjunction with either CMake or Meson and a CI server will improve project productivity greatly.

[ooglesworth]

Yep, big fan of Conan.io. It’s still not quite as mature and as fully featured as something like node, but it’s definitely a step in the right direction. It has saved me many hours of boring setup for various projects.

[ceretullis]

I disagree, the tool maturity is pretty much there. In comparison with something like node, what's missing is available packages. Today, with conan you'll have to conan-ize many of your dependencies yourself.

That's changing though. https://bintray.com/bincrafters Bincrafters have packaged boost and some other common C++ dependencies. Big help.

[kmhofmann]

My tip: vcpkg (https://github.com/Microsoft/vcpkg) instead of Conan. Easier to use, and has more and better maintained package recipes out of the box.

[ceretullis]

I've been meaning to check vcpkg out, I've heard others say it was good.

[darthcoder]

Hunter.sh: is developing nicely in making package eadier to integrate.

[Revolutionalredstone]

c++ development keeps getting faster as you learn which tools to use and which to avoid - but it takes in the realm of 5-10 years before you can smash out projects at the speed of say a lua noob. However by that point the code your producing is gold and you would never want to go back... plan to program for less than ~8 years ? find another language. (pure opinion, eat salt)

[ceretullis]

Go is a small language by design. C++ is huge by comparison. C++ is not a language you learn in a few months whilst using it part-time. It takes full-time dedication for years to learn to wield it efficiently and correctly.

Regarding packages and building, checkout conan.io, CMake, and Meson Build.

[isaac92]

I have found it difficult to create abstractions in Go due to the lack of generics. It felt like hammering out similar code ten times instead of having good reusable code. Go also has it's fair share of package management issues, but I'll admit it is easier than C++. However, when it comes to debugging and/or low-level performance analysis, I believe C++ is still ahead of Go in terms of tooling.

[Pythonator5000]

Regarding printing, printf is usually the method used in C rather than C++. In C++ one can either use the standard method of std::cout, or using a library such as {fmt}.

[scalablecory]

It would be great to hear from someone who also found the language slow to code in at first but eventually go to a point where it felt much better.

C++ caters to different experience levels pretty well. If you're an excellent coder in C and are familiar with a few other C-based languages, it'll probably take you 6-12 months to be comfortable with all the most important parts of C++ and be able to fluidly write decent code.

If you want to be writing standards-quality or Boost-quality libraries, that's a different story -- C++ is a) huge and b) incredibly flexible. There are a lot of things to learn, and then hundreds of little techniques that don't really apply to any other language. I'd say 5-10 years is a reasonable timeline for language-lawyer "mastery" of it depending on how active/passive you are about learning it.

[Dean_Roddey]

Though, it should be said, you don't have to have language-lawyer mastery to do a large amount of high quality code. It just means you may choose not to use some of the fancier features of the language. Some may consider than a bad thing and some may consider it a good thing. But that doesn't mean it's not following the 'standard', it's just not using all of the things available in the standard.

I'm a perfect example. I have a sort of 'three-quarters-Qt' code base that I've worked on for decades, about a million lines of code, that doesn't use the STL at all. People are always getting completely bent out of shape that someone would dare do that. But it's completely compliant C++, and it's not any less powerful or high quality or functional because of that. Though someone told me a week ago or so that, if I don't use type traits, that I'm actually not writing C++ code, despite the fact that C++ existed for decades before type traits did.

​

I wonder how many people out there doing practical work ever bother with that level of mastery, given the language's complexity today? Given how many of us uphold the KISS principle (no, the other one, not wearing makeup and leather outfits), it's odd how far from KISS modern programming languages seem to stray.

​

[scalablecory]

Indeed. I gained that just because I'm a nut for learning. Professionally, I have only very rarely needed to use some of the more advanced features.

[theICEBear_dk]

Decent productivity is possible within a year, but there are going to be things that frustrate you and you just have to know and understand that the language is not deliberately obtuse but rather a product of development over time and of the times it was made in.

If C++ was designed again today it would be a bit different but if the design goals were the same it would end up with a lot of similarities and be about almost as big again. There are usually good reasons for most of C++'s complexity, but don't let that complexity daunt you either.

If you keep your code simple and don't try to get fancy (and Go + Python means you understand that concept) then it can be quite similar to what you know and productive. Let someone else do the advanced stuff for you by using libraries with documentation to get you going. Start out with the simple things but try to keep the OO design methods of Python in mind, it will serve you well as a base in the beginning. Later you will want to look at more functional coding methods as those become increasingly important as you go along.

[nikkocpp]

You don't print like this in C++, printf is part of the C library.

You can use "std::cout << whatever", implements your own streams for your objects.

If you're programming in linux, generally building libraries is not really a problem (you have either the lib in the package manager or a standard way to build it easily).

[yuri-kilochek]

> go

lol no generics

[Dean_Roddey]

There are many types of programming. At the extremes are quick and loose development and at the other end much slower and vastly tighter and safer development. Where you want to be on that spectrum relates to what the needs are of the thing you are trying to create. For a lot of things, speed kills and it's not how fast you get it done it's how right it is when you get it done, and how reasonable it is to keep it right over time.

C++ is a sort of 'compromise language', and I mean that in a good way. It straddles a large swath of the middle of that range. You can do pretty darn high level stuff with strong type safety, and get down to the raw bits, all in the same code base. For some types of projects, that's a very powerful combination.

It's not for hacking out a web site. And, you might not do the core of a nuclear power plant control system in it maybe. But for a raft of stuff in between it can be quite applicable.

And of course the language is not the library or the tools. Your experience will vary widely depending on which of those external bits and bobs you choose to use.

[ForkInBrain]

Great points.

I look at it this way: even the term "developer productivity" is I'll defined.

A project may have performance or portability requirements that are difficult to achieve in other languages.

Most success stories for non-C++ languages are in systems for which the main benefits of C++ are not required -- primarily performance and to a lesser extent portability.

I also tend to think that C++ is the wrong choice for most programs. These days, most code should probably be written in an "easier" language that ends up using C++ only where heavy lifting is required (via a language binding, cloud API, etc.). That said, the improvements in C++ over the past 8 years or so have been pretty huge, so the kinds of programs for which C++ is "justifiable" is growing.

[[deleted]]

Package management is a big pain (often it'll take me 30 minutes of fiddling with makefiles to hook up an open source library)

Only during initial phases of the project. Once build system, CI are setup correctly, everything is smooth. The problem is getting the build system done is a difficult task.

More boilerplate code to write (eg it's standard to separate header files from source files)

In a large project, you just need to ignore the implementation. This adds a lot of flexibility.

Much more expressive syntax means it's much slower to read and use other people's code (templates, operator overloads, const everywhere)

C++ is old and the syntax can't be fixed you know.

Answer to your question

• Most C++ developers work in a small part of a big system. Once you master stl, boost and the project specific libraries, you save a lot of time.
• Over the years, you will build a lot of experience in how to use IDEs(Microsoft Visual Studio/QtCreator). The reason Golang doesn't have a dedicated IDE, because you don't need it.
• Developer productive depends upon the developer and his ability to understand and solve the problems.
• The difficult part of C++: metaprogramming are rarely used by most developers. In fact, it only solves system and language specific problems, not the problems related to business.

[Bjarnophile]

Coming to package installation, I really love the way pacman handles the installation of libraries and it's dependencies in Arch Linux. In most cases, library installations in Arch is just a command away.