2 ms·
>it's not something that would be difficult to replace That's very naive. It's just not something that hard to imagine to replicate. Why do you think a 26 year
by npteljes 4y ago
>it's not something that would be difficult to replace
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?
- IshKebab 4y agoBecause it's useful and it works? Also we didn't have as many HTTP implementations available in the past. 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.
- charles_f 4y agoCat is an interesting example because it's not as trivial as it seems, especially when it comes to performance and resilience: https://endler.dev/2018/fastcat/ https://endler.dev/2018/fastcat/ https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/ 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.