lysdexic

joined 1 year ago
MODERATOR OF
[–] [email protected] 0 points 2 weeks ago

Erm yeah because the whole point of monorepos is that you don’t use submodules. What?

Not true. The whole point of monorepos is that you track everything in a single repo. There is absolutely no requirement or constraint to avoid using specific features of specific VCSs or even package managers.

[–] [email protected] 1 points 2 weeks ago

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.

[–] [email protected] 2 points 3 weeks ago* (last edited 3 weeks ago)

Can you clarify how “Not even Github managed to pull that off”?

GitHub actions has an atrocious user experience, to the point that even a year or so ago people where doubting it was production-ready.

Sure, you can put together a pipeline. But I challenge anyone to try it out with GitHub actions and then just try to do the same with GitLab or even CircleCI or Travis.

The fact that people compare GitHub Actions go Jenkins of all things is everything anyone needs to know about it's user experience.

[–] [email protected] 15 points 3 weeks ago (10 children)

There would be no other incentive for companies to buy it.

A company might want to extend it's service offering with a build pipeline/CICD system, and buying GitLab would get them the best-in-class service.

Microsoft bought GitHub for much of the same reasons, and GitHub didn't went to hell after the acquisition.

[–] [email protected] 12 points 3 weeks ago (3 children)

I don't think it makes any sense to mention source hut because none of the features you mentioned are killer features (or relevant. Why should I care about implementation details of feature tracking?) and it completely fails to address GitLab's main value proposition: it's CICD system.

Anyone can put up any ticketing system. They are a dime a dozen. Some version control systems even ship with their own. CICD is a whole different ballgame. It's very hard to put together a CICD system that's easy to manage and has a great developer experience. Not even GitHub managed to pull that off. GitLab is perhaps the only one who pulled this off. A yams file with a dozen or so lines is all it takes to get a pipeline that builds, tests, and delivers packages, and it's easy to read and understand what happens. On top of that, it's trivial to add your own task runners hosted anywhere in the world, in any way you'd like. GitLab basically solved this problem. That's why people use it.

35
JSON Patch (jsonpatch.com)
[–] [email protected] 0 points 1 month 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?

[–] [email protected] 3 points 1 month 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.

[–] [email protected] 0 points 1 month 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.

[–] [email protected] 1 points 1 month 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.

[–] [email protected] 1 points 1 month 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.

[–] [email protected] -4 points 1 month ago* (last edited 1 month ago) (1 children)

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

[–] [email protected] 8 points 1 month 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?

view more: next ›