Hacker News Reader

My preference is to use C++ like a C with some extra useful features, and not "go full C++" by trying to "do everything the C++ way". C++ has a lot of features and is growing but, contrary to what a lot of evangelism seems to say, you are not obliged to use all of them. Use a feature when it makes the code simpler and the effort reduced, don't try to use one and complicate things just because it's a new feature that seems interesting.

This is how I feel. Even as a Unix/"Pure C" fanboy, just having the STL is a huge time saver.

When I started with C++, I thought the same way. Now, two years later, I look back at all that code and I'm thinking wtf is all that C code doing there. I guess I just appreciate a lot of the C++11 features much more now.

Precisely! Just because the features are there doesn't mean you must use them.

My use case for instance, is to use C++ as C plus the STL (yuck for doing everything manually in C as opposed to having neat classes that are easier to use and equivalent after compilation), useful C++11/14 features like auto type inference or lambdas, PoD structs, and little else.

http://learnyousomeerlang.com/

It's probably not as mind-bending as you think. The actor model is fairly intuitive. The difficulty is that it's fairly easy to have unexpected behavior from simple actor rules. And the syntax is kinda funny ('.' and ',' look too similar to me), but there is elixir if you want (although I think elixir is even weirder...)

There are a few things I disagree, but at least one is factually wrong. C++ is as fast as C, if nothing else because it's (almost) a superset of it.

The things C++ is missing include performance features. It's missing the "restrict" keyword.

https://en.wikipedia.org/wiki/Restrict

Some compilers offer "__restrict" or "__restrict__" in C++, but it's not standard. Standard C++ lacks the feature.

Besides "restrict", there is also the matter of theory not matching practice. The norm for C++ programmers is to be at least somewhat unaware of various extra copies and allocation. You know it's true. In practice, this makes the language slower.

C++ has std::valarray that has aliasing rules similar to the restrict keyword, allowing the same types of optimizations.

Forgive my ignorance, but doesn't std::unique_ptr communicate the same restriction, and therefore enable the same optimisations?

unique_ptr has unique ownership; it's not an error to use other pointers to the same data (just a bad idea).

>>The target audience for the code I write is not the compiler but my coworkers and the gals and guys who will maintain the stuff after I leave a project.

If the compiler cannot understand the code you write, I doubt your "coworks and gals and guys" are going to be much happy with you. Isn't code for both the compiler and programmers? >>So I prefer to choose a language where I can nicely express the intent of what I code. Java is a good compromise, because it's easy to follow (even if it's quite verbose and mainly stuck in the world of nouns).

I don't call verbose code nice, just like average people don't call verbose prose nice. It is personal whether something is easy to follow. To someone who has put in the time and effort C++ code can be easy to follow; I see no reason to denigrate one for that. >>Yes I know, C++ is more "capable" than Java but it's not efficient in the hours-spend-per-solved-problem way of things.

If I am going to spend 30 years programming, I am going to become more "capable." And I will spend LESS hours-per-problem because I have put in efforts to really understand the problems and gained insights. >>Yes I know, there are you C++ whiz kids out there who are insanely fast using the language. But I experienced teams using it, and in a team C++ does not scale well. Adding more and more features to it makes it a cool language, but not one which I like to use in my day job.

Some teams are built to use Java, others use C++. I do HPC and numeric analysis; my C++ skills is quite an asset to my team. >>And I'm not sure what I'd use it for. I use Java for the day-to-day boring "enterprise" world, twiddle around with dynamic languages for the hobby (yay to the recurrence of lisp!) and for close to the hardware stuff I'd use plain C - which is a not so bad language at all. And it's hard to beat speed-wise, writing C++ that keeps up with C is possible but not trivial.

I know what I use C++ for, as do other people. C lacks abstraction mechanism and is fragile. And it is actually not very good for today's hardware. Eigen library offers ease of use and good performance using template-meta-programming; I don't see any C library doing both. >>And if I'd have to look forward I'd check out rust or go or even look at some really mindbending stuff like erlang. Parallelism can't be evaded in the modern world and using a language tailored to that is a great thing. (Yea, I'm sure there also is a C++ library implementing the actor model).

Erlang employs one kind of parallelism, and there are others. They are suitable for different use-cases.

Look, it doesn't surprise me a Java programmer doesn't think much of C++. I get it, it is competition. I don't recommend Java to my team lightly either. But, really, you got to find better trash talk.