joined 11 months ago
[–] lysdexic 0 points 20 hours ago

There’s also alternatives with custom ci jobs within non GitHub/lab within the git universe that may help out with those sorts of operations.

Why would anyone subject themselves to explore nonstandard and improvised solutions to try to fit a usecase that fails to meet your needs to a tool that was not designed to support it?

Do people enjoy creating their own problems just to complain about them?

[–] lysdexic 3 points 20 hours ago

I don't think they did an exceptional job keeping teams separated. In fact, I think monorepos only end up artificially tying teams down with an arbitrary and completely unnecessary constraint.

Also, not all work is services.

[–] lysdexic 0 points 1 day ago

That's perfectly fine. It's a standardization process. Its goal is to set in stone a specification that everyone agrees to. Everything needs to line up.

In the meantime, some compiler vendors provide their own contracts support. If you feel this is a mandatory feature, nothing prevents you from using vendor-specific implementations. For example, GCC has support for contracts since at least 2022, and it's mostly in line with the stuff discussed in the standardization meetings.

[–] lysdexic 1 points 1 day ago

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.

[–] lysdexic 1 points 1 day ago (2 children)

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.

[–] lysdexic -3 points 1 day ago* (last edited 20 hours ago)

(...) 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.

[–] lysdexic 8 points 1 day ago

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?

[–] lysdexic 0 points 1 day ago* (last edited 1 day ago) (3 children)

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.

[–] lysdexic 3 points 1 day ago

named arguments

Is this supposed to be a critical feature?

[–] lysdexic 1 points 1 day ago (3 children)

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.

[–] lysdexic 6 points 1 week ago (5 children)

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.

[–] lysdexic 3 points 1 week ago* (last edited 1 week ago) (2 children)

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

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.

Well, it's just an AWS Account ID! (
submitted 1 week ago by lysdexic to c/loud
std::try_cast and (const&&)=delete (
submitted 2 weeks ago by lysdexic to c/cpp
submitted 2 weeks ago by lysdexic to c/loud
submitted 2 weeks ago by lysdexic to c/cpp
view more: next ›