I have used something like that (mentioned in my original reply ^). It was even worse -- there were about 3-4 plugins available.
Basically that company (a well known social media company, not FB) tried to implement everything on their own. Infra is their own (kinda makes sense because it is so huge), IDE is their own, communication is their own (which has an interesting feature that if someone screen shares an internal doc, other people can click a link to access that doc, too, very useful).
I was very jealous about their tooling team (that's what I call real programming), but nevermind I quit after a few months due to some unrelated reason.
Large monorepos have tradeoffs that may or may not make sense for a particular use case. Google's monorepo--in its form as a monorepo, not just the software it contains--is one of its biggest assets and creates enormous leverage.
And an enormous set of problems that must be managed. But multirepos have their own set of issues, and which set of problems you want is highly situation dependent.
I have always had this itch to work on some real life serious system programming projects, with the most recent wave OS kernels. I completed the MIT xv6 labs (a very small repo) and did a few Linux device driver labs (very large repo and it was the first time I experienced compilation time > 5 minutes).
I got burnt out after a while, so that kinda wrapped up my experience working on large repos.
It is basically VS Code Web. Try https://vscode.dev/ to see how you feel. If you don't like it you won't like cider.
I have used something like that (mentioned in my original reply ^). It was even worse -- there were about 3-4 plugins available.
Basically that company (a well known social media company, not FB) tried to implement everything on their own. Infra is their own (kinda makes sense because it is so huge), IDE is their own, communication is their own (which has an interesting feature that if someone screen shares an internal doc, other people can click a link to access that doc, too, very useful).
I was very jealous about their tooling team (that's what I call real programming), but nevermind I quit after a few months due to some unrelated reason.
Pretty much. Also it’s not that slow and you can’t just checkout all of g3
To be fair, that is a blessing. Large monorepos are a terrible idea.
Large monorepos have tradeoffs that may or may not make sense for a particular use case. Google's monorepo--in its form as a monorepo, not just the software it contains--is one of its biggest assets and creates enormous leverage.
And an enormous set of problems that must be managed. But multirepos have their own set of issues, and which set of problems you want is highly situation dependent.
I have always had this itch to work on some real life serious system programming projects, with the most recent wave OS kernels. I completed the MIT xv6 labs (a very small repo) and did a few Linux device driver labs (very large repo and it was the first time I experienced compilation time > 5 minutes).
I got burnt out after a while, so that kinda wrapped up my experience working on large repos.
thats just a large project tho? not necessarily a mono repo.
A mono repo doesn't necessarily mean large compile times, because it depends on the projects and their dependencies within that repo.