“I could rewrite curl”

Collected quotes and snippets from people publicly sneezing off or belittling what curl is, explaining how easy it would be to make a replacement in no time with no effort or generally not being very helpful.

These are statements made seriously. For all I know, they were not ironic. If you find others to add here, please let me know!

Listen. I’ve been young too once and I’ve probably thought similar things myself in the past. But there’s a huge difference between thinking and saying. Quotes included here are mentioned for our collective amusement.

I can do it in less than a 100 lines

[source]

I can do it in a three day weekend

(The yellow marking in the picture was added by me.)

[source]

No reason to be written in C

Maybe not exactly in the same category as the two ones above, but still a significant “I know this” vibe:

[source]

We sold a curl exploit

Some people deliberately decides to play for the other team.

[source]

This isn’t a big deal

It’s easy to say things on Twitter…

This tweet was removed by its author after I and others replied to it so I cannot link it. The name has been blurred on purpose because of this.

Discussions

Hacker news, Reddit

48 thoughts on ““I could rewrite curl””

  1. I guess you could do that in a weekend if You redefine weekend πŸ˜›

    1. Just get rid of weeks, turning everything into a weekend – problem solved!

    2. Make it the weekend between the fourth Friday and the last Monday of September, 1993.

  2. (insert one of the many quotes about critics here).

    I would be interested in your take on what was the most time-consuming aspect of developing curl. Was it portability issues, working around bugs in the OS, dealing with broken web server HTTP implementations, or the increasingly baroque nature of HTTP?

    1. Fazal: that’s a really hard question to answer, given how much time and effort I’ve spent on this by now and the fact that I’ve never measured time spent. I mean, accumulated over time I’ve removed almost as much code as I’ve added. I’ve fixed numerous things that later was fixed again and my original fix or code was totally overwritten and forgotten. Doing Internet protocols to interop can be very tedious and no protocol is easy or without complexity when scaled up to everyone on the globe.

      The most time consuming thing of making curl has been to maintain stability, behavior and performance over two decades. πŸ™‚

  3. So…can we get a dedicated page for this and call it “Daniel’s Grill and chill”?

    1. I’m sure one of the helpful people quoted above could get it done in a weekend for you why don’t you ask them instead

  4. Oh, thank you! Finally, random people from the internet who you definitely you can trust make real judgements for your work and made honest and truthful calculations.

    I’m not sure that I ever can remember all existing command line options for the curl. Rewrite it? Nah, it is too complex to imagine what is hidden in 27k commits.

  5. hahahahahaha

    I am sure they could “write” curl in a weekend

    By Monday they will realise how limited and buggy their rewrite is, throw it away and just write an arrogant blog post “what I learned from rewriting CURL in a weekend”

    1. Honestly – I love curl, even though I’m using it mostly as most people use a Swiss Army knife. It’s great to have a multi-tool, but you mostly use the knife.

      But, I go to sleep knowing well that whatever issue tomorrow might throw in my face I’ll always have curl to help me out – as long as it’s http-related.

      @Daniel: love your work! Keep going strong!

  6. Point them to https://news.ycombinator.com/item?id=27220136 and save your breath!

    Thank you for CURL. I’ve used it for half my life. As a web developer/programmer, without it perhaps my life would have been different, that’s my reality.

    The worst part of their “thinking” is how many services they’ll be relying on that use CURL under the hood without them realising.

    Cheers

  7. Daniel, but why bother? Serious developers know the value and effort of curl. Why bother with these offhand and self-aggrandizing remarks from others?

    1. Senthil: because I think it’s fun and because they are used as references in lots of my day to day communications so its good to have a canonical source to point to.

  8. Psh. Let anyone one of them try. If they could do it in a weekend, let them write it and post it and wait for the issue reports to roll in. Oh, and they don’t get to use any libraries that do the heavy lifting. They need to handle HTTP/HTTP2/FTP/SMTP/etc… with cookie support, multiple protocol versions, redirects…. all without any security problems.

    I’d bet not a single person would actually even attempt it yet alone deliver on something.

  9. I can do it in one line and two weekends:
    import requests, sys; print(requests.get(sys.argv[1]).text)

  10. Those comments say more about the commentators than about Curl and the effort that went into it.

  11. With Gemini protocol it’s definitely possible to rewrite a client in few days.

    With HTTP, the length of the specification makes it impossible.

  12. Thank you for your effort in writing and maintaining curl. It is a great piece of software I install on pretty much every computer I work on. It is useful in so many ways.

  13. I can provably make this kind of statements in a matter of seconds. Literally! ?

  14. CURL is awesome – don’t let anyone tell you differently. It’s an invaluable library and tool.

  15. Meh, noobs. I could rewrite curl by forking it while having s___, and I only last 5 seconds. How fast is that huh?

    /s sarcasm intended

  16. These ignorant dipshits don’t understand software development, nor the immense value of the software you have created.

    Please do keep up the excellent work and disregard these foolish haters.

  17. I’m not surprised to see the Dunning-Kruger effect on display πŸ™‚

    Honestly I’d be surprised if there aren’t offers to do it in some high level language that, hidden to the hopeful author, has curl as a dependency.

  18. This seems petty. That curl isn’t trivial is an indictment of the standards it implements. It amused me that the bemoaning of “No reason to be written in C” is immediately followed by criticizing people who sold an exploit. There’s no connection at all, right?

  19. We have a saying in French: the yaka faucon technique.

    These are make-up words from “it just needs to be done” and “one has to…”.

    Pretty much as all the magical coders who could do this and that but somehow something is constantly in the way.

  20. Well don’t get bummed out.. it turns out a lot of self titulated “programmers” are in fact idiots.
    -“There is no reason why it has to be written in C directly”…
    In fact, choosing C was a good idea. It’s going to be significantly more portable and easier to link to. Also.. directly? Not sure what he means by that? Is he trying to say that it should be written in some crappy higher level script. In fact, there is no good reason why it shouldn’t be written in C.

    -“I can write it in (insert imaginary number here)”…
    Was probably written by an investor or a scriptkiddie, or both.. “I can do that too, let me just include these 5 other network libraries, glue them together in less than 100 lines of python code and pretend like I created a new API”.

  21. Pffft… I once re-wrote curl in assembly with my eyes closed on the toilet. I admit it was a very large shit so I was in there for about half an hour. Real programmers use wget anyway.

  22. From my experience writing toy implementations of a TLS 1.2 client and of a HTTP proxy – these things were easy as long as you implement what is in the standards without worrying about outside bugs, attack attempts, or performance.

    All of these things have tremendous impact on the implementation complexity.

    1. Exactly. It’s true, it’s easy enough to write a basic HTTP client… you can bypass the client entirely and just speak HTTP yourself over telnet if you really want to.

      It’s the edge cases that kill you… the things that might not matter for any given scenario, but a good HTTP client needs to deal with all of them.

  23. curl is one of my favorite programs, and reading it’s source code is like reading a poem – long live to curl, and thanks again

  24. Ah ah ah thank you for sharing! Also having the links will help them become famous given that apparently it’s the only thing of interest to them (and us developers can safely ignore their resumes if they ever dare sending them).

    Another one I’ve heard once was someone asking how many lines of code there were in haproxy, divided it by how many lines one of his best devs could code in a day to estimate the time needed to rewrite it. Great laugh as well, we still regularly quote that one at the coffee machine! Too bad he didn’t do it, it would have been amusing to watch the monster once the deadline was met πŸ™‚

  25. The irony is you can actually say that you’ve rewritten curl yourself, at least to much more of an extent than anyone who claims they could ever will.

  26. Don’t take any of these guys of seriously. These folks don’t know what there are talking about. I can safely say that you did great work over the years. (However, I’m also not the biggest fan of network-related things in C either, but that has nothing to do with curl.)

  27. Daniel I am always amazed whenever I remember you’re not incredibly well staffed, funded and supported by private industry. All of whom use your blood, sweat and tears to lubricate their devel. One of you new “crypto-billionaire” whizz kids KICK THIS MAN SOME MONEY!

  28. It’s funny how people deliberately share their lack of knowledge.

    Maintaining a tool over 20 years (If I’m not mistaken), following all the ever changing RFCs, innovations, changes et cetera isn’t an easy feat.

    And a lot of products like HAProxy / CURL / … have become a de facto reference for me – not (only) in source code, but also in “how did CURL / HAProxy tackle this and what was their experience in dealing with it?”.

    I’m really thankful for all the long living projects and their maintainers keeping them alive.

    Some libraries have nowadays a life span of less than 1 year.
    Which makes everything incredible hard – from maintaining projects using it to gaining insight in how the library works (if the maintainer jumped off the band wagon, they’re incredible tough to reach usually).

    So… Thanks to all the maintainers and team members who keep projects alive.

Comments are closed.