[flagged]
https://daniel.haxx.se/blog/2021/10/15/curl-installations-pe...
Most who make a living out of it work on the project as part of their jobs at larger tech companies or universities. A few manage to start a company around that project and make a living selling various licenses and support. A tiny number manage to (at least temporarily) scrape together a living from donations.
For a large number of them however being an open source maintainer is an unpaid hobby they do on their evenings and weekends.
But it should be a solved problem by now. No need for continuous full-time work.
HTTP 2/3 are mostly bad ideas (slightly less bad in the case of 3, but still overkill) pushed by Google to optimize an edge case no one but web browsers care about.
curl doesn't fully support HTTP 3 regardless.
Not yet in command-line, but libcurl has support. Besides, that's the task to work on full-time :)
https://curl.se/docs/websocket.html
> to optimize an edge case no one but web browsers care about.
I'd argue there are no reasonable use-cases for HTTP except web browsers.
Every time comments like yours come up I'm just thinking "yeah, the fucker have no idea how much handling of edge cases comes up with libs like that"
So your thinking appears to be inaccurate.
Probably not full-time, but some software are never done
From his website. They wouldn't give him a full-time position if there wasn't enough to do.
While the curl CLI is ubiquitous in our world, libcurl is embedded and used all over the place. Given that it has always been well maintained and enhanced I do not see a lot of reason to create alternatives or for someone to look to replace it.
I wish I had known this before.
However I mostly use wget from shell, and since I mostly work with python aiohttp/standard library/just writing the request on the socket.
Why don't you stop being intentionally vague and tell us which ones, and what makes them better?
Because if there is something better than curl, with its enormous scope in protocols and platforms, and free of charge to boot, I would surely like to know.
Curl's installed base is enormous. If everyone who uses curl had to switch to some other solution tomorrow, that would mean millions of developer hours wasted. If anything, the author of curl should be paid more.
curl supports 28 transfer protocols [1]
> There are better ones.
curl has 60 language bindings, runs on 89 operating systems across 24 CPU architectures [1]
So what is that mythical better client (that only does HTTP)?
[1] https://daniel.haxx.se/blog/2022/11/25/89-operating-systems
cURL isn't a HTTP client.
It's a command line tool and library for transferring data with URLs :-)
And what happens when I need something more, or something else? I need to find a different "better client"?
But usually curl.
Without knowing your requirements it would be difficult to say.
Say for example your main concern is latency, you only need support for MTU-sized payloads, you want ro guarantee that the TCP connection is always established ahead of time and your requests always follow the same pattern with a few bytes to tweak.
You can easily write something that can do those things much better than curl in a couple of hours.