Hacker News Reader

Comment by mike_hearn | Hacker News Reader

> We have shipped hyper support in curl labeled EXPERIMENTAL for several years by now, hoping to attract attention and trigger the experimental spirit in users out there. Seeing so many people seem to want more memory-safety, surely the users would come?

This analysis seems off. Memory safety isn't a feature users will explicitly ask for or opt-in to. What users want is software that isn't buggy, and they just sort of ambiently expect it. A "Rust backend" is pretty meaningless to users, a bit like expecting users to pass a --dont-be-buggy flag to every invocation of the CLI tool.

As a user, I'd have questions like: if this backend is better then why isn't it the default? Why do I have to make a decision at all? I just want an HTTP library/tool that doesn't let me get hacked, how it achieves that is none of my concern really. Whether that's done using Rust or not isn't something that should appear in the user interface.

View on HN

If you want to read a bit of Rust community criticism into the Article, I think it would not be too far off to read this as “There are lots of people claiming writing things in Rust provides better software due to memory safety, but in practice users did not care and were perfectly content with the C implementation” (presumably because the latter has no noticeable bugs).

I also interpreted the article a bit that “users” here refers to developers that make use of libcurl, that would overall like to ensure that the application that they are writing does not segfault or similar. It seems plausible to assume that some of the Rust goodwill would translate to developers that may also try to migrate their overall code to Rust to try out that backend, and potentially contribute improvements. The Linux kernel and Git for example seem to attract a lot of attention of people that want to work on migrations towards more Rust.

Hyper can't be the default if it doesn't pass the test suite (that's the bare minimum). And after years there weren't enough contributors to fix all the remaining bugs.

I would agree that the curl project itself should have put more effort in fixing those bugs and eventually remove the C HTTP/1 backend, not the Rust code. That's what happened in Firefox for example, and other projects that adopted Rust incrementally.

I think this has to be put against the larger context of Rust… fans that push very hard for the entire world to be rewritten in Rust. Just look at how many Rust projects where their front page / README has the first line as "written in Rust" as if that's the number 1 feature a user should care about. As such I think there was an outsized voice of re-writting cURL in Rust and whatnot as occasionally there will be buffer overflow bugs that admittedly would not have existed if the code in question was written in Rust. That's why there was the experiment to add a new backend using Hyper because in theory they should not be prone to the same class of memory bugs.

As for why not making it the default, the post already made it clear? The new backend did not pass all the tests and therefore could not possibly be the default backend until that was fixed and turned out fixing the last few issues were quite hard. cURL has also supported different backends for a while now. For HTTP/3 for example you can swap out the backend for something else. This is like driving a car. If you literally don't care at all, just use the stock tires/engines and it will drive fine. But sometimes you may care and swap out the stock components for something else that suits your needs, and cURL allows that. cURL / libcurl gives a stable ABI as a glue but it's intentional that you can swap out the backend.

ah, the classic "--bugs" / "--no-bugs" flag

--bugs / --other-bugs

Reply on news.ycombinator.com