If you hang out on HN, you see this kind of statement a lot, it's happens so often (more than any other language right now, used to be TypeScript), it's the outside perception of the ecosystem. If they chill out on the superiority claims, that perception can change like it did for TypeScript.
Updates mean you have to copy over all the code into your repo, which creates a large diff, and hope you aren't overwriting any local changes someone might have made.
It bloats your repo, both with the actual code, and the large diffs when you update it.
You have to manually track new versions, without something to tell you if new versions are available, or if your version has known security vulnerabilities.
If the dependency has it's own dependencies, you have to vendor those too recursively. And if multiple dependencies have the same transitive dependency, it is up to you to deduplicate them, and make sure you have a version compatible with all dependents.
The biggest problem isn't (usually) disk space, or network bandwidth, it is that git operations slow down as the size of the repo grows. And it means that cloning or pulling the repo takes longer, which can be especially problematic for CI.
> Recursive dependencies have the same issues whether you vend them or not.
Package managers usually handle resolving recursive/transitive dependencies for you. Some have support for vendoring dependencies, but not all do. In theory, you could have similar tooling for vendoring dependencies, but in practice that often isn't the case.
Vendoring isn't a clear win for security. It may provide some protection against "supply chain" attacks, but makes it more difficult for you to respond to vulnerabilities discovered in the version you vendored. And for business continuity, in many cases depending on an external registry is an acceptable risk.
And both of those concerns can be addressed by using an internal/private registry that mirrors the packages you need.
But in any event, your original question was to elaborate on why vendoring is inconvenient. Whether or not the benefits are worth the inconvenience is a different question, to which IMHO the answer is "it depends". Sometimes it is, and sometimes it isn't.
> Vendoring isn't a clear win for security. It may provide some protection against "supply chain" attacks, but makes it more difficult for you to respond to vulnerabilities discovered in the version you vendored.
How so? Whether a dependency is vendored or not, you still have to update it to integrate a security update to that dependency, don't you? The alternative is to not pin your dependencies, but that is far riskier overall.
> Whether or not the benefits are worth the inconvenience is a different question
I would contend that it is the most important question. :-)
If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk. If I want to upgrade the disk on my work laptop, I’m SOL.
> Ensuring that diffs to updated dependencies remain within a vendor folder is trivial.
It’s not obvious to me how putting the dependencies in a vendor folder solves the diff problem. Does every code host allow you to hide diffs to certain directories?
And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
> If I want to upgrade the disk on my MacBook Pro, I need to buy a new MacBook Pro with a larger disk
Is this a significant risk in reality? MBPs today come with a minimum of 1TB of storage. Even 5 years ago I think the minimum was 256 GB. This is more than large enough for all but the most massive repositories, even with vendored dependencies. And you can always plug in external SSDs or HDDs or connect to a network server.
> And what’s the advantageous scenario for vendored dependencies? Is it just when the mod proxy and the upstream code host go down at the same time?
This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
> This is more than large enough for all but the most massive repositories
Consider the possibility that the drive needs to accommodate more than just a single repository?
I have lots of software, entire language toolchains, AI models, Docker images, application volumes, VMs, etc.
And this isn’t a theoretical concern; I have to free up space every few months.
> This is a useful homework assignment. Ask your favorite LLM or consult some respected release engineering books. Also consult your local AppSec and infosec teams.
So there is no advantage scenario that you’re aware of?
> Syntax highlighting is juvenile. When I was a child, I was taught
arithmetic using colored rods
(http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I
use monochromatic numerals.
Wow, that second link does exactly what I do when I'm talking to people about skittle highlighting; demonstrating a skittle highlighted snippet of prose to show how absolutely harmful it is. I only started doing that maybe three years ago, so they've got me beat by 15 years or so! Glad I'm not alone on this crusade, at least. It is genuinely my belief that skittles have cost humankind millions of manhours of productivity, at minimum.
Not convinced at all by these reasons. Rob Pike has long stepped down from the Go team so it shouldn't matter? This is a website not a language change.
> I think the perf jump from Ruby to Rust is much greater than .NET Core to Rust
This has not been true for me. If you are constrained by memory, you will still come out better using Rust, even if you use C# with AOT. We use .NET 10 at work and see 1/5th of the memory being used by a ported Rust service. Your mileage may vary.
Those numbers don't really mean anything. Claude Code has millions of users, and that issue forum is the most obvious place for them to ask questions or request features.
If there were 11,000 open and confirmed bugs then yeah, that would mean the software is bad.
No one knows how many bugs claude has because Anthropic auto-closes Issues (or at least used to) if there isn't someone constantly pinging the issue every two weeks. I've contributed to several issues that were confirmed by several other people, which were they were auto-closed after people gave up confirming the problem without any response from Anthropic. They seemingly don't care if it isn't on fire or at least smoldering heavily, which seems really bad in my book if you're trying to make even reasonably good software.
Curl is great, but I think you're vastly underestimating the surface area of CC.
It looks like it has more in: editor integrations, multiple guis and tuis, config variations, external systems (eg, git, mcps, curl-like requests?), statefulness (curl is "only" request response), inner runtimes (eg, sandbox per OS), sensitivity to its environment, possible side effects of its own execution, potential interaction combinations, etc.
Curl has hard system-level code requirements but it's design space feels more bounded and predictable to me.
> I think you're vastly underestimating the surface area of CC.
That is one of the reasons CC code is so low quality. The amount of extra unnecessary code just to implement it using React is by far the worst technical slop decision I've seen made by so called "software engineers" in a long time.
I dont't really know stats about such things, but I assume the adoption of CC has been insane compared to almost anything, and is also like two years old? Yeah, not surprised.
But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
Havent used CC in some time, worked fine last time I tried.
> But also, if they all use 500 agents daily and latest models can "one shot" everything, one would think 5k issues are fixed in no time...
IMO, CC should be the poster child of what LLM coding should "feel" like. If things are so good why are there so many issues? Why can't they get a handle like other well-run projects? As you said, they have unlimited tokens so this project should be close to pristine as much as possible.
Not OP, but I think the leading and trailing paragraphs were mostly human-written (and nice to read), but the memory leak example cases had a very different flavor of prose and code comments that smelled very Claude-y to me
> So anything that has em dashes is now considered LLM generated?
Is that what they said? If that's not what they said, why are you putting words in their mouth in an attempt to weaken their statement into some completely ridiculous stupid strawman that is obviously not actually what they said?
That’s the first thing others point to being LLM-generated. If you see, right after the phrase you quote, there is a question as to what else OP thinks is LLM-generated. I didn’t put words into anyones mouth
It's unfortunate, but to come across as genuine now I think you have to actively avoid AI-isms.
In this case it feels AI generated with human polish, or vice versa. A couple tells are "One caveat worth stating up front..." and of course, "...the shape of the language itself...".
> It's unfortunate, but to come across as genuine now I think you have to actively avoid AI-isms.
I actually think this might be a good thing? I'm way more aware of cliches and filler in my writing these days, and it almost always reads better when I just remove them and plainly say the thing.
Don't get me started as well on how the iCloud plans jump from 200gb to 2TB with absolutely nothing in between. Apple really knows how to extort their customers!
That's not just an Apple thing though. Google does the same thing. Dropbox only offers 2TB plan. OneDrive is just as expensive but offers 1TB.
They are all counting on you not using all of that space in the 2TB plan. So the avg user is subsidizing the usage of some small fraction of power users. They don't want to offer pay-per-use pricing plans because then they would have to increase the price ($/GB/month) to keep their existing margins.
This is one of the very techniques under which the entire Apple Empire has been built. They take the "sweet spot" for $product and intentionally offer options on either side of that sweet spot. They also nerf the lower-end option in other ways (i.e. fewer ports) so to make the upgrade more enticing. This enables them to offer "Prices starting from...." that are dead-end options (like 8GB RAM or 128GB HD's).
Lots of companies do this across various industries. But it works best when the brand name is really strong and/or the competitive landscape is very weak.
I've grown to accept that it's just how they operate.
Apple should not be allowed to have a monopoly on iCloud. They ought to be forced to have an open spec such that competitors could offer alternative cloud storage services.
One person != "the ecosystem"