Hacker News Reader

> There isn't any point of using C++ to count words in a text file. Any high-level language like Python will beat you to it.

Well, I think that Python will probably do that in the shortest code but it is also more or less the slowest language which is today widely in use, at frequently about 1/50 the speed of C.

You of course could write the example in the link in Rust but for a quick script with decent performance, at around 1/6th of the speed of C, I'd probably use Racket. Racket is really a pretty sweet spot between performance and expressiveness.

> C++ is a tool. And like every tool out there it has its uses. [ ... ] While you don't need it in most of the cases ...

The thing is that the space in which C++ is really useful and the best solution is more and more shrinking. If one wants to control the hardware registers and write a kernel, I think C is still best. If one aims for safety and an performance equal to C, Rust is by now a good choice. For example in the task given in the original article, it would correctly process Unicode without any extra effort. It is of course complex, but much less so than modern C++. If one wants to get things done quickly, Python has its place, but I think Racket and similar languages (babashka) have many advantages. If things get more abstract, Ocaml might be an interesting choice. And I think for parallelism on the server, Clojure and Scala are pretty good.

What happened is that, once upon a time, programs in C++ or C were far far faster than anything else, and Java programs were as slow as a slug. But, compilers got better, and this has changed. And also, modern software development is source-code centric, not based on compiled Windows DLLs, much of the used code is in libraries on Github and elsewhere on the net, and it turns out that for this kind of code reuse, functional languages are often a better fit. Now, C++ is still competing with this and adopting functional features, but the result is getting more and more complex. At the same time, languages like the mentioned ones are getting better and better compilers, and they are conceptually far far simpler. And the speed advantage of C++ is shrinking steadily. In fact, by some comparisons it already does not exist any more:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> fully control the memory layout of your data.

This is, looked at closely, not more than a means toward an objective, and that objective is performance. Control over the memory layout is normally not a value in itself.

> * Try implementing an on-disk hash table in Python and you're stuck manually packing ints and longs in an out of arrays. In C++ it could a simple template used with a memory-mapped file.

This can easily be done if you use LMDB. In fact, using it might be faster and LMDB allows for safely accessing the data from multiple processes. LMDB is written in C and of course there exists a Python library for that.

> * Try doing anything non-trivial on a microcontroller with 32KB of RAM.

You can use uLisp on the Arduino:

http://www.ulisp.com/show?1LG8

> * Try designing an application-specific data structure in any other language. Let's say you have an ~8GB in-memory database that slowly adds records one-by-one and then invalidates them in chunks.

Sounds perhaps like a use case for InfluxDB, which is implemented on top of LMDB, by the way.

> What it means in practice, is that unless you have an existing project that uses C++ anyway, you want to partition it: do the memory-critical part in C++, and communicate to it from a higher-level language via a high-level interface.

That's of course possible and is arguable often done that way. But there is no necessity to use C++. You can do the low-level, performance-critical part which needs some control over the memory layout in Rust, and do the rest in Racket, for example. The functional nature of Racket will make parallelism in the Rust part easier. I've tried that and it is really really neat.

Just to say, I've been using C and C++ professionally since, well, now 25 years. And this along with, for example, Python and IEC 61131-3 Structured Text, which is used to program PLCs. Of course, C++ is entrenched and will continue to be used for a long time. There is also heavy investment and interest in industry. But, it is not as essential as C for the hardware access part and there are today a number of interesting other options. I think C will be used for a loooong time from now, but I would not bet my house that C++ is being used as widely 20 years from now.

(The issue with Python is that it is easy to get started with it, and write small personal projects in it, but for the case of programming reliably in-the-large, and using a lot of dependencies, it is showing its deficiencies).

View on HN