geezerjay

> I bet the compile times would improve if it wasn't header only.

If any hypothetical compilation time problem concerns you then rest assure that C++ enables you to develop submodules that wrap and instantiate your templates, eliminating the need to recompile them every single build.

> I should clarify. Being able to add headers to a project in C++ is easy but adding translation units is not (usually).

Where do you see a difference?

>This encourages header-only libraries even when they are not really appropriate, increasing compilation times etc.

Thus assertion makes no sense. Headers only declare interfaces, and you only require headers-only libraries if you're deep in template and template metaprogramming land. Evenso it's quite trivial to package and distribute those libraries just like any other library

I don't see your point. Adding custom build steps is a basic feature that's supported by pretty much every single popular build system for decades now, just like adding your own dependencies. Heck, cmake even allows users to configure a project to download packages from the web and integrate them in a build and with custom build steps if needed. Even if we ignore this fact, there are also package management tools such as Conan which handle this case quite nicely and also support cross-platform deployments.

And let's not pretend that in some platforms such as pretty much each and every single popular linux distro already package and distribute C++ libraries and offer packaging tools and also package repository services to distribute any dependency.

I'm starting to suspet that those who complain about these sort of issues have little to no experience with C++.

IMHO returning status 400 is only reasonable if the request itself is malformed. A request to check whether a CC is valid does not become malformed depending on whether the CC is valid or not.

> It is ridiculous that header-only is considered an advantage.

Why do you believe it's ridiculous? Being able to integrate a third-party library by just adding a few source files to your source tree is as simple as it gets.

> The state of C++ build tools is very poor, and it is harming the language as a whole.

This assertion makes no sense, particularly in the light of this discussion. Installing a headers-only library is a solved problem, and even template-heavy libraries such as Eigen are already distributed and installed quite easily with standard linux package managers.

The decision to go with a headers-only design is only required if you want/need to provide templates.

Furthermore, it's ignorant to conflate headers-only libraries with a problem or a shortcoming.

> Taking advantage of so many extra cores by a single process is not all that easy or common.

Browsers are both multiprocess and multithreaded. The ability to run a few webapps without having your system drag to a halt is a feature that's important to essentially everyone.

Smart pointers are strangely absent from this comment, which is rather weird as handling raw pointers ceased to make sense and became a pungent code smell with the inception of C++11.

> these days it's even considered "disruptive" if you offer a couple of scooter for rent. Whom are you disrupting exactly?

Public transportation, and how people move around a city?

Sure, it's scooters/bikes/cars/helicoptera for rent. But being ubiquitous and affordable makes it usable and in some cases even preferable than established solutions. That changes a lot of stuff. Heck, airbnb is just a middleman in renting deals, right?

> But how does it compare to

Wattaboutism does not address the man's problems, including all the problems he brings onto himself, the company he runs, and its investors.

> Perhaps there is a reason for the industry not to like him since he's competition

You're commenting on a man who accused a cave rescuer of being a pedophile after he criticised mr Musk's brain-dead proposal to rescue the stranded kids.

The problem does not lie on strawmen such as this silly idea tha the industry does not like him.

Comparatively, service-per-vm approaches are very wasteful and ineficcient, moreso if a container orchestration system is used to manage the deployment. It makes no sense to fine-tune VMs just to match the resource requirements of a single process, particularly as they change over time and as that approach leads you to a collection of custom-tayloted VMs that are needlessly cumbersome to manage and scale.

Meanwhile containers enable you to run multiple services on the same VM, scale them horizontally as you need on the same pre-determined amount of resources, use blue/green deployments to spread your services throughout your VMs automatically, and achieve all of this automatically and effortlessly.

> And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter.

Sometimes the burden of maintenance is the price you have to pay go get an operational/production system early on and enables you to let other requirements emerge earlier.

You might focus on the "burden of maintenance", and also assume that you're saving time by taking the long route to production, but letting requirements emerge early on in the project is also a significant time saver as it enables the project to avoid committing the mistake of investing time developing a goldplated solution that will have to be thrown out.

You need to accept the fact that the "burden of maintenance" is always there and it will always be there, whether you invest years rolling your goldplated solution or just dash to production with a quick and dirty solution. You don't get rid of that burden by aiming for an academically pristine implementation that takes ages to deliver. Requirements do change, and do so continuously. Heck, designing stuff for a scale that will never be required is also a major problem. So, why would anyone be concerned with having to spend 120% of the time developing a solution if that path enables you to get up and running in 20% of the time?