Hacker News new | comments | show | ask | jobs | submit login

I use C++14 extensively and I have to disagree.

There are no channels, there are no lightweight/green threads, there's no standard HTTP library, no standard crypto libraries, no standard test framework. For certain classes of applications this makes Go significantly more productive and significantly less bug/error prone. Not to mention compile times.

Even the nicest things in C++14 suffer from backwards-compatility-ism i.e. awkward syntax, and endless incomprehensible garbage output from the compiler when you make an error e.g. inside some complex templated code. As C++ devs we manage to live with that stuff but it still sucks.

Even if your code uses some nicer subset with standard libraries you typically need to interface to a whole range of things that do not comply with that subset. Be that something like a Cassandra driver that uses libuv or OpenSSL with its native C interface. Any C++14 beauty that may have existed is gone and your code is now subject to all those subtle memory management, buffer overflow, and concurrency issues.

I used to think garbage collection was garbage but I've start to appreciate how much simpler it makes my life (Even over RAII smart pointers) for very little cost in Go.

Python, Ruby and Javascript are a completely different kind of language so I'm not sure it's worthwhile comparing those to C++. There are many things you can do in Python that you can't do in C++ and that's mostly a good thing ;)

That said there are certainly some classes of applications where there's no substitute to C++. It's also much nicer than it used to be. But it shows its age.

I completely agree with you. The lack of a module system (still missing in C++17) and of standard libraries that are commonplace in other languages (testing, string formatting...) are the two most serious drawbacks which are preventing me from using C++ anymore.

The fact that there is a nice subset of C++ which works well is not a valid argument, in practice. As you say, you are forced to include in your projects a lot of libraries, each assuming its own definition of what this subset is, and the union of those subsets can be a monster.

You can grab Catch as a test framework. It's a single header file you can include directly in your directory and it takes like 2 minutes to learn how to use.

Thanks, I didn't know about Catch. However, my point is that this kind of tools should be part of the standard library, like it's the case for other modern languages.

Standard libraries are where libraries go to die and get ossified. I prefer the C++ model where you can pick best of breed solutions.

It sounds like you're doing web dev and for that I wouldn't use C++. As you pointed out, languages have different advantages and disadvantages. I was just trying to point out most people don't seem super well versed in modern C++ so it gets undue hate.

I usually build embedded systems, desktop apps, and even some higher end computing applications. I use QT in conjunction when I need most of that stuff you mentioned, as that framework makes it easy. Also,

> there's no standard HTTP library

I mean, there isn't a standard library, but cURL is easy to use.

I'd classify the systems I work on as "cloud"/systems work. So not exactly what you'd call "Web" but close enough to the kind of use cases Google designed Go for, i.e. their infrastructure. We've managed to make C++ more or less fit better through mountains of in-house libraries and code.

I've used C++ with Qt in building embedded applications and my experience was mostly good. Then again Qt had its own types which were incompatible with C++ and a fair bit of work was getting more or less standard C++ mated with Qt. I remember writing a lot of glue code that used Boost.Signals2 ...

On one hand it's true that people who still see C++ as C with classes and don't use things like lambdas, algorithms, smart pointers, STL data structures, are contributing to some hate/misunderstanding of C++. On the other hand, C++ developers who do use the modern features get used to all the quirks and don't understand why others don't see what we see ;) So we just maybe std::move, or inherit from enabled_share_from_this without thinking twice and know the difference between && and & and the new lambda syntax but really, as a developer, most of the time, why should I care? To some extent a camel can't see its own hump.

What you're saying is basically exactly what I would have said 2 years ago before I started using Go more heavily. Now it's mostly C++ because I have to and Go because I want to... Not that Go is perfect but the stuff that it does well it also does easy.

I get the problem, but I don't think experienced C++ developers should pamper inexperienced (or unwilling to learn) C++ developers by avoiding features that are considered best-practices. Template programming with Boost.MPL? Sure, I regret every time I used that - I've gained little, and very few developers will be patient enough to learn how to maintain this code. But avoiding std::move() and and R-values just because other developers may get confused?

By all means, if your developers are unwilling to learn modern C++, use Go - it's easier to learn. I agree that's it particularly well geared for any network IO-heavy server. C++ can give you better performance, but it probably requires 5 times the effort.

I'm not saying to avoid those in C++. I'm just giving that as evidence that writing C++ is more difficult than Go. Sounds like we're in agreement.

> I mean, there isn't a standard library, but cURL is easy to use.

Unless you want windows compatibility. GP isn't necessarily doing web development from the description though, just something that uses a network.

What are you saying? Both curl and libcurl are available for windows.

What percentage of machines would have it? I doubt it's higher than 1% even for programmers.

I also didn't mention earlier that curl is probablly not a replacement for an http library. There is some overlap in use cases but neither can replace the other.

I think you're assuming that "use curl" means "shell out to /usr/bin/curl", which is, of course, a terrible idea.

I'm pretty sure the gp was instead suggesting that you should use libcurl, which is the library that powers curl-the-command-line-utility.

One thing that always pissed me off in the old days was on one side we had nice libraries like Turbo Vision, OWL, VCL, and then we needed to resort to pure C like code for accessing a database via ODBC, or some image manipulation library, for example.

So for some sanity, I always spent some days writing sane, type safe, C++ wrappers.

But this always fails flat when working in teams that don't share the same quality goals, without directives from above.

I full-heartedly agree. My general impression as someone that has learnt most of C++ afted C++11 is that the biggest drawback to the language are colleagues who either want to "just write C" (and in my experience also tended to riddle whole projects with resource leaks) and/or suffer from "that's not the way I learned it, thus it has to be rubbish" as their lead mentality.

Thought-trough, modern C++ code is IMHO quite often more readable, elegant and generally more pleasant than anything I've seen in C# or Java so far. But it's all hampered by the poor code some people ham-fisted in before or afterwards...

So, at least for me, C++'s biggest drawbacks are many of its users, not the language itself. Interestingly, that's something thad e.g. the Python community seems to have way more success managing, although Python as a language checks almost all boxes that should - in theory - foster quick hacks...

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact