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?

If you have tangible results then present your benchmarks. If you limit your marketing to empty claims regarding "the future" and vague assertions on performance then you're actually actively working to lower your credibility.

Why are you hoping that the proverbial pendulum swings away fron Hadoop?

But claiming that "X software is written in Y language/framework" says nothing about efficiency or safety. It's just meaningless marketting piggy-backing on popular buzzwords.

And claims about "the future" are simply absurd. Oddly enough, this link appears right next to another story on how Cobol powers the world's economy.

Frankly, I'm surprised blockchain wasn't shoved somewhere in the announcement.

> "Apples and oranges" is a metaphor for things that shouldn't be compared.

No it's a reference to comparisons that don't make sense.

You can compare as many apples you'd like with oranges, just as you can compare air travel with roadway traffic, but you'd be making absurd and meaningless comparisons.

> I don't understand your objection.

The objection is obvious and very easy to understand; it tries to compare apples with oranges, and here you are trying to argue that they are both fruit.

Some universities require their researchers to publish and follow reference journals, the majority of which has been managed/hijacked by for-profit editors. As researchers are forced to meet publishing quotas, there's a negative feedback loop that forces research groups to have no alternative other than following and publishing on these journals.

The article is well written, and easy to understand. FTA:

> Norway has found a radiation level 800,000 times higher than normal at the wreck of a Russian navy submarine.

>(Snip)

> A sample showed radioactive caesium leaking from a ventilation pipe, but researchers said it was "not alarming", as the Arctic water quickly diluted it.

An assurance from a random guy on an internet forum is hardly assurance.

> and copy over the whole root (/)

Why on earth would anyone do that? That's simply wrong on so many levels, and is far from being standard practice.

> You CAN NOT mount a drive with "docker build".

No one said that. I stated the fact that you can access files from the host during a docker build, thus it's irrelevant if you can mount drives or not. Just copy the files into your build stage and that's it.

AMD's Ryzen 3700X has a TDP of 64W. You'd be hard pressed to find a desktop processor that outputs less than that.

> there are plenty beefy rackmount units available on Ebay,

Old rackmount units on ebay that provide more than 16 or 24 threads typically require >1000W PSUs to power the server's multiple 120W processors.

AMD's Ryzen 3700X packs 16 threads and has a default TDP of 64W.

I believe the whole point is that adding unnecessary software to a container also increases the attack surface unnecessarily.

> because docker build does not allow you to temporarily mount the cached dependencies.

Why do you believe this point is relevant? If you can mount a drive then you can access its contents on the host, and if you can access files on the host then those contents are also accessible in a Docker build.

> This isn't really about "getting the latest version", it's about "getting the latest security patches for a stable version."

Typically security patches trigger new releases with minor/patch version number bumps, which are then installed by getting the latest version of the package. That's pretty much the SOP of any linux distribution.

> They prevent easier program concatenation and ad hoc parser writing.

This assertion is patently false. Parens make it quite trivial to parse and render the underlying tree structuee rather obvious. Concatenating programs is just a matter of splicing a subtree into the target tree.

> Exactly so. But, you have to use a proper editor with automatic indent, paren matching, and the ability to navigate by s-expressions.

Autoindent and paren matching is currently a basic feature of virtually all mainstream text editors. Therefore, picking up any random mainstream text editor is already enough to address your concerns.