lysdexic

(...) you can see what’s going on with the rest of the company, too.

That's a huge security problem.

Edit for those who are down voting this post, please explain why you believe that granting anyone in the organization full access to all the projects used across all organizations does not represent a security problem.

I'm inclined to interpret monorepos as an anti-pattern intended to mask away fundamental problems in the way an organization structures it's releases and dependency management.

It all boils down to being an artificial versioning constraint at the expense of autonomy and developer experience.

Huge multinationals don't have a problem in organizing all their projects as independent (and sometimes multiple) source code repositories per project. What's wrong with these small one-bus software shops that fail to do that when they operate at a scale that's orders of magnitude smaller?

Still no contracts?

In line with the release process for C++ standard specifications, where standards ship every 3 years but alternate between accepting new features and feature freeze releases, C++23 was the last release that was open to new features. This would mean C++26 is a feature freeze release following the new features introduced in C++23.

named arguments

Is this supposed to be a critical feature?

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.

Bloating HTTP and its implementations for REST-specific use-cases

I have no idea what are you talking about. Setting a request/response header is not bloating HTTP. That's like claiming that setting a field in a response body is bloating JSON.

Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

Taken from https://datatracker.ietf.org/doc/html/rfc6648

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

I still work on software that extendively uses X- headers.

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

It's interesting that the internet is packed with search hits of complains that Cloudflare's DNS is slowing everything but Cloudflare representatives are quick to post followups pointing the finger everywhere else.

Asking this question is like asking when was the last time you had to search through text.

Aside from the obvious UX disaster, Git has some big issues:

I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.

What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.

Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.

There are no hard set rules, and it depends on what uses you have for the build number.

Making it a monotonically increasing number helps with versioning because it's trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It's not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.

You sound like you're focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.