Comment by guggle | Hacker News Reader

Comment by guggle | Hacker News Reader

Parent Full thread

As a non-C++ programmer having to deal with C++ from time to time I don't really have a problem with the language (yes, it's huge, but there is no need to use everything) but with the tooling. Especially it's never clear to me how I should deal with dependencies and build systems, it's all different from project to project and often feel like a kludge coming from languages where setting up the environment is not much more than one or two commands. Even dealing with maven files and maven central repository felt easier than most C++ projects I had to work with.

In lieu of C++ we hear a lot about Rust these days, with focus on performance and reliability. But I suspect the rate of adoption is such because of the productivity aspect (it seems to me the language itself has non-trivial concepts and its fair share of syntax cruft from what I saw): having integrated tooling, dependency management, all being a de facto standard for the language. Same for Go, it's just very easy to start a project, add a library, compile a project... everything is included.

I guess it's probably not a priority for experienced C++ programmers as they are probably used to it, but I'm sure more people could build stuff in C++ without those barriers.

The tooling is improving. It's so much better than it was. With CLion I have a modern refactoring IDE of excellent quality (just don't try to use it with large code bases like Chromium, though, ahem). Build systems have improved remarkably. We have two excellent open source compilers.

I actually enjoy working in modern C++ much more than I did in Java, which I did professionally for almost 10 years before this.

I like the idea of Rust, and followed it since the earliest days when Graydon proposed it. I like the syntax and the tooling. But every time I begin a project in it, the cognitive overhead of the memory safety features just throws me a loop. I have no doubt if I were to dig into a large and established code base using it it would click within a few days, but starting on my own... I lose focus quickly.

I do like Zig, though. It is a very nice C++ alternative.

> I actually enjoy working in modern C++ much more than I did in Java

What do you like about working in C++ more than Java?

Generally, I hear from people working in C++ that it's the only tool for their job, and only use it because no other tool measures up (in a despairing tone). If you don't mind my asking, what do you use it for?

I am not the person you're replying to, but in my experience / opinion if you want to do distributed high-performance numerical computing, executing on heterogeneous hardware, C++ is really far and away the best language to get this done. If you're CPU-only, maybe Fortran is a better option but when GPUs enter the mix I don't see how you're going to have an easier time getting the requisite performance with anything else.

I mean, like, you can interface with TensorFlow via Python but the big-kid parts of the implementation are in C++ / CUDA.

http://blog.plover.com/prog/Java.html

I feel great joy coding C++, more than any other language. C++ is built to be used. Every part of it was put in to solve real problems, and they do. I can write thousands of lines of code, and when it finally builds, the program works first time.

More systems level stuff than you'd ever use Java for. Google/Nest hardware devices (display assistant devices, other stuff).

The Rust ecosystem does a lot of what it does by mostly punting on dynamic linking. The community is happy to compile the world and distribute it in a statically-linked binary.

This makes things a lot easier on both developers and end users but does not in theory scale well with increasing adoption (end users have a bunch of huge binaries bundling the same subset of libraries which all get hit with zero-days at the same time but are updated piecemeal across the apps bundling them). The tooling and package management stories are a similar case - they haven't fragmented yet, but as adoption increases you start having to deal with shit like packages from obscure hardware vendors and commercial language tooling - including compilers, providing functionality either absent from or superior to what's available in in the de-facto-standard project templates. Examples from my experience would be things like the Intel C++ toolchain, MPI compiler wrappers on supercomputers, and vendor-provided toolchains targeting alternative devices like CUDA.

Perhaps their community will deal with these challenges in a super-elegant way, I'm not ruling it out. But I'll believe it when I see it.

The thing is, half of what you described is basically a Linux-ism.

It's irrelevant on Mac, Windows, Android, and iOS, where the operating system is a monolith that applications depend on. Technically, it might be made up of multiple libraries, but the OS is almost guaranteed to be present in full, and it's the only thing that can be guaranteed to be present, and it might use integration systems that applications cannot or rarely use (VDSO, NTDLL, syscalls obviously, but also stuff like the System calling convention).

Or you might just use IPC for all components, like Plan 9.

It's also irrelevant if you're using a bare metal machine with no filesystem, a system with a weird linking paradigm like webassembly, or if your app basically owns the entire computer.

I don't think it's controversial to say C++ tooling is rough. I do think a large number of C++ engineers think that they can care about the language so they don't need to care about anything else, including build systems.

I also think a large amount of C++ is tied to a native platform, packaging system (or source repository), and possibly a native build system. That means the tooling is fragmented, though not universally poor. It's just that the tooling is not always available.

Reply on news.ycombinator.com