Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“I Could Rewrite Curl”

daniel.haxx.se

Post reply on HN
Print view View original

101–110 of 193 posts

Re: “I Could Rewrite Curl”

#101

Post by michaelbuckbee »

parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

In the midst of so much open source drama and angst, I'm still just profoundly grateful for Daniel Stenberg's work on curl.

I'm no expert on open source management but Daniel has for years been a positive and steady force working on curl.

This is him publishing the direct criticisms he's receiving as "thanks" for his efforts and it guts me he's got to put up with these ignorant comments.

Re: “I Could Rewrite Curl”

#102

Post by ahefner »

vardump wrote: post #74
bombcar wrote: post #46

Earlier quoted context omitted.

An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.

Weird. First idea that came to my mind was to use a linked list of lines.

It works. Many editors have used this approach.

Re: “I Could Rewrite Curl”

#103

Post by dvfjsdhgfv »

vardump wrote: post #74
bombcar wrote: post #46

Earlier quoted context omitted.

An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.

Weird. First idea that came to my mind was to use a linked list of lines.

What would you use for a line?

Re: “I Could Rewrite Curl”

#104

Post by meepmorp »

slooonz wrote: post #84
thrower123 wrote: post #22

Earlier quoted context omitted.

I wonder what percentage of attempts to rewrite curl in modern languages end up eventually just calling code from libcurl if you trace down through their standard libraries far enough?

What standard library uses curl for HTTP ? AFAIK, none of Go, Python or Node does.

"PHP," he said with a shudder.

Re: “I Could Rewrite Curl”

#105

Post by WORMS_EAT_WORMS »

eps wrote: post #44
parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

> SMB Woah. This is genuienly impressive.

As someone who fell into the category of:

> "Most folks I know don't even know about the other protocols curl supports and have only interfaced with curl through its http."

Just curious if you could elaborate on this one specifically and why you found it especially interesting.

Re: “I Could Rewrite Curl”

#106

Post by dkarl »

parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl?

I can see the advantages of standardizing on a complex, powerful tool for simple use cases. For one thing, it may be the only way to standardize: simple versions are too easy to write, and therefore you get dozens of competitors, none of whom are popular enough to shake out their edge case bugs.

It's also nice not to have to find, install, and learn a new tool when you stray over that 90% boundary.

With software dependencies, I think the advantages of small, simple libraries win out over generality. Supporting powerful use cases makes an API more complex and often means that simple, 90% use cases require weird incantations to make them work. Here I think of the times I've had to get into the guts of Jackson despite never doing anything remotely exotic with JSON. The 95% of your codebase that can be simple should be simple, so you can devote your attention to the things that need to be complex.

Re: “I Could Rewrite Curl”

#107

Post by bjoli »

bombcar wrote: post #46
ezequiel-garzon wrote: post #43

Earlier quoted context omitted.

And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month for what I understand was the first version of ed(1): [...] [my wife] was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself [...] [1] https://www.princeton.…

An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.

Today I would probably reach for an RRB tree and define some kind of simple heuristic for transients, giving me free undo/redo, and reasonably simple support for multiple cursors. Back then a gap buffer seems like a great idea. Two linked lists is a simple enough idea.

Re: “I Could Rewrite Curl”

#108

Post by ceejayoz »

viraptor wrote: post #91
ceejayoz wrote: post #89

Earlier quoted context omitted.

> Nobody should expect it to be maintained in any way. Which is the exact problem of "I could rewrite this in a weekend!" scenario with curl, right?

It depends if the rewrite is meant as a joke or a serious minimal implementation.

I don't think it does. curl has been maintained for nearly 25 years now; there's a benefit to that, and I'd need someone to come up with very compelling reasons to write a new implementation before abandoning it beyond "my code is shorter".

Re: “I Could Rewrite Curl”

#109

Post by jmcqk6 »

slooonz wrote: post #84
thrower123 wrote: post #22

Earlier quoted context omitted.

I wonder what percentage of attempts to rewrite curl in modern languages end up eventually just calling code from libcurl if you trace down through their standard libraries far enough?

What standard library uses curl for HTTP ? AFAIK, none of Go, Python or Node does.

I'm not that familiar, but I believe php does

Re: “I Could Rewrite Curl”

#110

Post by mumblemumble »

krick wrote: post #68
parhamn wrote: post #30

Let's be honest here. Curl to 98% of people is http/1 requests with some post params and maybe json body, with some custom headers. Most language standard libs (which might be using libcurl) can facilitate writing that relatively quickly. And probably with a more 'modern' CLI. Curl though, is a very wide breadth project. It currently supports the following protocols: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP,…

True. I'm kind of surprised (again) by Daniel after 20 years of maintaining curl being so salty about "people not appreciating the achievement". Yes, for overwhelming majority of users curl in 2021 is just a simple http/https request client. And, yes, in 2021 that could be written over a weekend with a better CLI, mainly because most of the languages already have all important stuff implemented in a [standard] librar…

That was honestly my first thought. Of course it's easy to rewrite curl nowadays. It can't be anything more complicated than slapping a command line interface on top of libcurl...
Post reply on HN