It's not. The main application of libcurl could be very easily replaced. Just because it is widely used (assuming it is) doesn't mean it is valuable.
You wouldn't say `ls` is critical infrastructure.
You wouldn't say `ls` is critical infrastructure.
It's like... you might use your phone's timer app all the time. But if it suddenly started nagging you for donations all the time you aren't going to donate; you'd just switch to a different timer app. It isn't uniquely valuable.
That's very naive. It's just not something that hard to imagine to replicate. Why do you think a 26 year old project exists, if it's something that could be replaced by a 100 lines something? Is the author stupid, or does he just include a lot of cruft and boilerplate? Are Apple and all the other users wrong?
How old do you think `cat` is? Does that mean it would be hard to replace?
> Is the author stupid, or does he just include a lot of cruft and boilerplate?
I never suggested that. Curl had it's own HTTP implementation. A replacement would obviously not do that. Also curl supports a gazillion protocols that almost nobody uses.
https://endler.dev/2018/fastcat/
https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/
I think this is one of these "not built here" discussions. It's very easy to underestimate the number of edge-cases to support especially in the case of network transfer. You start implementing your own, then you've got to handle non standard certificates, 300 redirects, temporary failures, backoff strategies, optimizing chunk size, handling proxy calls, etc. Using a standard library makes sense.
(And critical IMO means 'important in fact' not 'not replaceable in theory'.)