Why does everyone here seem to dislike C++?

Try learning Python, Java, Erlang/Lisp/OCaml/Haskell, Prolog, and then look back at C++. You'll see what's the reason.

Expressing yourself in languages like Python is much easier than C++. You'll be able to concentrate more on solving the problem at hand than dealing with the language.

I highly recommend these two short books:

https://www.amazon.com/Treading-Python-Beginning-Programming...

http://www.amazon.com/Treading-Python-2-Intermediate/dp/1490...

Compared to plain C, C++ tends to become unmaintainable. Everybody knows a tiny subset of the huge language, yet must somehow work together on a team. People do not stick to a common subset of the language that everybody is comfortable with, especially considering team members that will be hired in the future.

In theory, C++ can be as fast as C. (officially lacking the "restrict" keyword, but otherwise fine) In practice, C++ is much much slower. The theory is no help. C++ code runs slow. People layer on the abstractions.

Suggested next language:

Well, although Rust and Ada look nice, I'll tell you what I use at work. I use C99 and lots of assembly. I do assembly for x86 (16-bit, 32-bit, 64-bit), PowerPC, ARM (original, thumb, thumb2, aarch64), ColdFire, MIPS, and many stranger things. Oh, don't forget the build system tools: bash, sed, GNU make, awk

For an EE, C++ is a pretty good language, in that it lets you get very close to the hardware. Most of the people who criticize it don't work in that world.

I think its just personal taste and preference. It also depends alot on the kind of projects interests you to work on.

Go with what you like.

Apart from school, let me give you an advice.

If you have a brain that can handle multiple levels of OO in c++ across multiple threads; keeping multupltformness in mind and crunching out optimized code with all that you learned in your data structure classes, stick with C++.

The pay is way better (like three times more here in Toronto) than anything web or app related, the working hours are more sane, and stuff are usually way more planned in advance.

You'll have way better life sticking to the shops that need your engineering coding skills.

Think carefully and be ready to wait out few months for your first job when you graduate. Charging jobs after is hard. App/web/testing shops will take a decent low level engineer any day of the week. A financial/embedded/engineering company will think long and hard before they hire a web dev for a backend/driver team dev.

In this proffesion you are beign paid to think. Why not approach your career choices similarly?

'everybody making fun of c++' is a non issue. You may as well worry about what wasn't cool in kindergarten. C++ was and is an industry standard.

On a unrelated note: this post will reflect the HN community by their impulsive up/down voting it ;)

People get very hung up on the complexity of the language and all the bad code one could potentially write. I use a C++ compiler to compile my preferred subset of the language, and for me that's within epsilon of the best of all possible worlds. If I was on a team that forced me to use every language and library feature, I'd probably be unhappy.

C++ is very hard. IMO, that's why people dislike it.

I was writing a test output parser in Python: ~50 lines of functional code in less than an hour. Testing the script for about 10-20 mins and tweaking it to my liking.

The same in C++ would've required me to look up/read up a bunch of library functions that I've forgotten (Should I use file I/O, string manipulation C functions or C++ functions?), link to a few libs (non-C++11) or read some obscure documentation on C++11's regex implementation. Compile, test, change, repeat. This is way more time spent as compared to the Python option.

This is not a fair judgment of the language, but my point is that for something simple there are other languages. For something complicated, C++ has been used in many applications (successfully and unsuccessfully). But there is no doubt that once a C++ code base becomes large it is extremely hard to maintain.

From a gaming industry perspective, Jonathan Blow gave a great presentation about his problems with C++:

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

C++ has lots of issues, most of them due to backward compatibility and versatility. Also, the language is very complex and enormously hard to master. I've used C++ for quite a while and everybody I know who used the language for at least a few years have developed a love&hate relationship for this language, or abandoned it.

To answer the titular question: I hate C++ because I worked in it for 10 years, and I came to realize things could be otherwise.

I almost came back to the language with C++11, but its core problem remains the same: the only maintainable codebases seem to be those strictly ruled over by language experts with an iron fist -- and too many people think they're experts (hint: if you haven't read the language standards (or written them!) and hacked on a compiler or two, you probably aren't an expert).

You inevitably have to choose an opinionated subset of C++, which often results in a language which is more on par with many modern languages, but with more pitfalls and traps, and which you have to teach to every person you bring on board.

And let's not even start on compile times and other problems C++'s legacy brings with it.

FWIW, I still do a lot of C and assembly. Modern C is pretty nice, although it will be nice to see a newer systems language finally take over.

You will probably end up doing C++ professionally, and that's fine, but for your own sake and the sake of your coworkers, learn some other languages that will broaden your mind.

You can find many suggestions in this thread, and I could go on about the more mind-broadening ones (logic programming, dependent types, metaprogramming, etc), but the most valuable might be another systems language, even if it's not popular, just so you can see how things could be otherwise. I think reasonable candidates might include Ada, Modula-3, Rust, D (which is a little too close to C++), BLISS if you can track down a compiler, Forth; maybe even Common Lisp.

Not everyone here dislikes C++. C++ is a good language for some things, and a bad language for others. In particular, C++ is not a good fit for web development and an especially bad fit for the type of web applications that the majority of people on HN work on. If you had asked people who make AAA games or create more performance sensitive applications you would likely see a different opinion of C++.

I for one don't. C and C++ runs the software that runs the world. From operating systems to embedded systems to browsers to whatever you can think of. Even the interpreters/VM's of all other languages (Python/Java/Ruby/...) are written in C/C++. All other languages have about 0.1% of the impact that C and C++ has. People who love other languages hate that. And haters will be haters. I for one am super happy that people choose other languages. Please do that! Less competition for me.

Name me one programming language that people don't make fun of. There aren't any. And why do you care anyway? Pick what works for you.

For me a lot comes down to the tooling.

* How do I start a new project

* How do I build/test/cross compile the project

* How do I add dependencies and optionally vendor them

If someone could 'reboot' c++ so it ships a decent standard library and update the tooling to work something like go or rust I'd be interested.

One of the projects I've been working on in go parses some csv files, stores the data in a sql database and presents a simple http json rest api. Could I write this in c++? yes. Do I know how to do all the bullshit needed to get a c++ project going that includes csv+sql+json+http libraries? no.

When you learn/taught any new programming language you learn about the primitives of the language and how to combine them to create programs. You will create simple programs to test the understanding of the language and get used to the features of the language in terms of how to solve a problem. On the other hand, the world of professional software development is very very messy, instead of creating program you end up creating these enormous complex software systems. Most importantly its not like that you get requirements, you implement them and you are done, instead you will keep getting new requirements over time which in most cases are conflicting with the existing requirements and the system needs to keep evolving to handle this mess forever. Handling this evolution over time is the most important feature of any language/tools/platform and it seems those people who don't like C++ have been through the frustration of handling that evolution of software in C++.

There is only one thing "wrong" with C++ and that is undefined behavior. An accident of history, but one that will make you cry at times. For the rest the tooling around it is quite depressing as well. But none of this prevents you from getting great work done, they are annoyances. i.e. you can have a solid career with C++ so the languages to learn are suggestions for horizon expansion not career advice.

Now it looks like you want to stay close to the hardware so there are a few options that can be interesting to look at. Game programming is not nearly as much fun as game playing so be careful what you want.

Rust: the new kid on the block, learning this will help you look different at C/C++ and even if you don't continue using it professionally you will pick up nice things.

A scripting language with a REPL. Lua, JS, a lisp, python, perl, ruby, it doesn't matter. Just have a look at one and see what tools to make tools you can build with them.

The following I would suggest having a look at but not more than 1 weekend each ;) They are very far from windows apps and game stuff.

Ada/spark: the old kid on the block, a could have been interesting. Again not something that is widely used so learn for curiosity not for career.

JavaCard: the slow kid on the block. Not talking about plain java here, but specifically the JavaCard environment which is a whole different playing field. You will pick up standard Java as well, by doing this. Massive different perspective, but no games ;(

Outside of languages I would spent time picking up Vulkan the new graphics API and OpenCL or Cuda. These will help with getting into the game market but also help you look at visualization and data presentation. Valuable skills no matter where you go afterwards.

Remember in the end people don't pay for code. They pay for solutions to their problems. If you can solve problems you will always have a job.

While C++ has plenty of interesting and nice features to play with it lacks something important Java has, reflection. C++ would be pretty close to "perfect" language if it would add reflective capabilities on top of all the other nice features.

Yes. I know some libraries add "reflection" but its not good enough. It needs to be baked in language and not require additional syntax on classes to be used as data for your own reflective code.

Because what I can clearly express in one line of swift/haskell/etc is often like 15 lines of nasty in C/C++. And when I make a mistake, the former has around a 90% chance of telling me about it immediately whereas the later is maybe 30%. When you're dealing with a couple person decades of code, that really really matters.

It's kind of like building a house using a rock instead of a hammer. It works. But after a few years building houses with a rock....when you try out a nailgun for the first time......yea not going back to that insanity. Of course sometimes a rock is your only choice...embedded, and a few other domains, but I'm never writing another line of C++ unless it's genuinely the only language that can solve the problem. To be fair, if you stick with EE, then yea it may be your only choice most of the time.

Also, as a counterpoint to the C++ makes more $$ comments. I doubled my salary(and got way more job offers) going from embedded C to iOS dev. Most of that's attributable to moving out of an economic backwater, but C/C++ is not necessarily a magic ticket to more cash. Being the company expert in C++ might be, but then so is being the company expert in <whatever>. I'd be lucky to see any increase at all moving back to C.

It varies per person. The history of imperative programming branches off from ALGOL into several directions. One was to C and then C++. Here's my point-by-point trace of how those were "designed." You'll see that C is more an accident of history designed to work on ancient hardware then lots of uptake since UNIX was written in it. C++ was actually designed carefully on top of C with features from many languages but inherits C issues and kludginess of that approach.

http://pastebin.com/UAQaWuWG

Now, there were a few other paths from ALGOL. One was Wirth's tradition of languages that were simple, type-safe, memory-safe as possible, compiled lightening fast, consistent, and still performed well. Started with Pascal with Turbo Pascal and Delphi being big commercial successes. Drawback with him was he leaned too far to simplicity as some features might justify extra complexity. Yet, the Oberon's, Modula-3, and Component Pascal derived from this style could do much of what C++ developers could with more safety, consistency, and development speed. Examples below:

https://en.wikipedia.org/wiki/Modula-3_%28programming_langua...

http://blackboxframework.org/index.php?cID=why-program-in-co...

http://www.freepascal.org/

Another branch was Ada family. It was designed to prevent as many faults as possible in embedded programming mainly. They systematically eliminate them with syntax, semantics, and defaults. SPARK variant extends that to automatically prove absence of common errors in code via formal verification that runs behind the scenes. The systems were never popular for various reasons but empirical studies by military showed vastly lower defects than C or C++ with productivity and maintenance advantages.

http://www.adacore.com/uploads/technical-papers/SafeSecureAd...

http://libre.adacore.com/

So, ignoring functional programming and such, it's hard for me to like C++ coming from a Pascal background where the syntax was readable even to lay people a bit (a la BASIC), operations were safe by default, compiles up to 100kloc/sec on Pentium3, no segfaults, less hacks, GC by default, unsafe for speed if I need it, and small set of features all developers understand and use. C++ was nothing like that although they've improved it a lot over time.

So, given I know better stuff is possible and even out there right now, I have to still think C++ is crap because it combines pieces inconsistently to approximate stuff like I use plus builds on an unsafe foundation with undefined behavior.

Because it adds complexity, but doesn't deliver the gains in productivity or encapsulations that you hope for.

C++ is a big language, and most people agree that "some parts" of it are useful, but they just can't agree on which parts are the good ones. You have to decide that for yourself.

This is worth reading for a good suggestion of how to use C++ features sparingly:

"Orthodox C++" https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b

Everyone has their own opinions, from dogmatically never use anything c++ to only stopping short of using boost. I will vary by project, using STL sometimes and not others, sometimes using classes lightly, other times sticking to POD, etc. I think you have the right idea when you say "Use it to get what you need done".