I thought it had been closed by the mods or admins.

I'm the mod and the guy who created the community, so I dare say that was not the case.

From the article.

Josh Aas, co-founder and executive director of the Internet Security Research Group (ISRG), which oversees a memory safety initiative called Prossimo, last year told The Register that while it's theoretically possible to write memory-safe C++, that's not happening in real-world scenarios because C++ was not designed from the ground up for memory safety.

That baseless claim doesn't pass the smell check. Just because a feature was not rolled out in the mid-90s would that mean that it's not available today? Utter nonsense.

If your paycheck is highly dependent on pushing a specific tool, of course you have a vested interest in diving head-first in a denial pool.

But cargo cult mentality is here to stay.

I don’t use chat, it’s usually useless.

I think Chat is the most useful feature of Copilot. Prompts like /docs work impeccably, but /explain and /optimize is also pretty good. /tests is hit-and-miss if you have zero tests and require too much context if you already have them. More often than not /fix is a waste of time.

Where I found Copilot to be quite useful is something unexpected: naming things. You can prompt it to give suggestions, you can ask it to refactor things for you. Quite nice.

I think that Claude is far better at generating code, and explore new stuff, but Claude is also down and broken extremely often,not to mention it's annoying limit of 10 questions per half a day.

I use chat the most. It's pretty good once you understand the importance of building context, set up personas, and feed it workable prompts. The biggest mistake I see people do is presume that you can expect it to output gold when inputting garbage.

Once you build up an understanding of what personas work for your personal tastes and what context you need to have, it can output impressive results. The most success I've been having is with somewhat complex refactorizations. Stuff like "refactor X so that Y and Y" can save you a lot of time.

The most disappointing experience has been with writing unit tests. copilot has this infuriating tendency to remove old tests when you're prompting it to add new ones. You need to explicitly request it to append tests to file X without overwriting existing tests for it not to mess up, and even then results are sketchy. For unit tests it's also important to setup good contexts otherwise whatever time you save by prompting copilot to write them will be wasted refactoring code to use specific frameworks and follow specific styles.

Neither does Git though.

Doesn't it, though? I mean, you can update a submodule's history directly from the consumer package. That's the whole point of submodules. Otherwise you would be better off by just wget something into your project.

You just referenced two languages that don’t have proper sum types. lol.

You're complained about "Proper HTTP implementations in proper languages".

I provided two concrete examples of two of the most popular and production-grade programming language ever developed.

I can provide more.

You then tried to weasel out by moving your goal post from "Proper HTTP implementations in proper languages" to "languages that don't have proper sum types".

I won't waste more of my time with you. Whatever you're posting lacks relevance and does not justify any attention from anyone.

I would only recommend a monorepo if you’re a company with at least 5,000+ engineers and can dedicate significant time to internal infra.

It's funny because at least one FANG does not use monorepos and has no problem with them, in spite of being at the same scale or even perhaps larger than Facebook.

I wonder why anyone would feel compelled to suggest adopting a monorepo in a setting that makes them far harder to use and maintain.

Proper HTTP implementations in proper languages utilize header-name enums for strict checking/matching (...)

I don't know what you are talking about.

Java provides java.lang.Object.HttpHeaders, which is a constants class that provides static final String fields for the popular request and response headers.

.NET does the exact same thing with it's class Microsoft.Net.Http.Headers.HeaderNames.

I can go on and on.

I don’t see why using submodules as a package manager should excuse their endless bugs.

I don't know what are these "endless bugs" you're talking about. Submodules might have a UX that's rough on the edges, but there are really no moving parts in them as they basically amount to cloning a repo and checking out a specific commit.

Do you actually have any specific, tangible issue with submodules? Even in the cases you're clearly and grossly misusing them

Agile is not a system. It’s a set of principles, set by the Agile manifesto.

The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.

I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .

ccache folder size started becoming huge. And it just didn’t speed up the project builds, I don’t remember the details of why.

That's highly unusual, and suggests you misconfigured your project to actually not cache your builds, and instead it just gathered precompiled binaries that it could not reuse due to being misconfigured.

When I tried it I was working on a 100+ devs C++ project, 3/4M LOC, about as big as they come.

That's not necessarily a problem. I worked on C++ projects which were the similar size and ccache just worked. It has more to do with how you're project is set, and misconfigurations.

Compilation of everything from scratch was an hour at the end.

That fits my usecase as well. End-to-end builds took slightly longer than 1h, but after onboarding ccache the same end-to-end builds would take less than 2 minutes. Incremental builds were virtually instant.

Switching to lld was a huge win, as well as going from 12 to compilation 24 threads.

That's perfectly fine. Ccache acts before linking, and naturally being able to run more parallel tasks can indeed help, regardless of ccache being in place.

Surprisingly, ccache works even better in this scenario. With ccache, the bottleneck of any build task switches from the CPU/Memory to IO. This had the nice trait that it was now possible to overcommit the number of jobs as the processor was no longer being maxed out. In my case it was possible to run around 40% more build jobs than physical threads to get a CPU utilization rate above 80%.

I was a linux dev there, the pch’s worked, (...)

I dare say ccache was not caching what it could due to precompiled headers. If you really want those, you need to configure ccache to tolerate them. Nevertheless it's a tad pointless to have pch in a project for performance reasons when you can have a proper compiler cache.