3 ms·

Hmm, wasn't it the other way round? Curl using a Rust library (hyper) instead of Rust programs using curl? Disclaimer: Just reading TFA, not an active Rust pro

Hmm, wasn't it the other way round? Curl using a Rust library (hyper) instead of Rust programs using curl? Disclaimer: Just reading TFA, not an active Rust programmer.

pornel 2y ago
Yes, but curl-with-hyper needed Rust programmers to finish and maintain the integration with the C codebase, and couldn't find anyone interested enough, which I assume is because Rust users don't need curl.
- aragilar 2y ago
  It sounds like a lack of funding (i.e. the grant ran out) was the real issue. Given how high profile curl is, this raises the question of how sustainable rewrite-in-rust efforts driven by grants (or other short-term funding) are, if they don't have an existing rust community to take advantage of the grant.
  - pornel 2y ago
    This wasn't a rewrite-in-Rust effort, and I think that's the problem. Nothing valuable from curl has been rewritten in Rust. Only some existing Rust code has been added to curl, but the Rust ecosystem already has a better, safer way of using that code. Curl is not planning to ever require Rust, so the rewrites are limited only to optional components, and can't fully guarantee that the code is safe. The Rust components are required to expose an unsafe unchecked C interface for the rest of curl. C compilers are unable to enforce the safety invariants of the interface, like the Rust compiler would in a program fully written in Rust.
    - aragilar 2y ago
      Probably I misread the original announcement, but I got the impression this was a pilot to adding more rust to curl (and is exactly what a rewrite would start to look like)?
      - pornel 2y ago
        The original announcement explicitly said it's not a rewrite, multiple times: https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp... > A rewrite of curl to another language is not considered > This is not converting curl to Rust. > Don’t be fooled into believing that we are getting rid of C in curl by taking this step. Curl plans to live and die with C: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ This has been reaffirmed recently in https://daniel.haxx.se/blog/2024/08/06/libcurl-is-24-years-old/ https://daniel.haxx.se/blog/2024/08/06/libcurl-is-24-years-o... > There was never any consideration to use another language than C for the library […] Not then, not now. Not only curl is rejecting possibility of being rewritten in Rust, it's also committed to supporting completely-Rust-free curl, because they pride themselves on supporting a lot of retro/niche platforms that Rust doesn't exist on.
- IshKebab 2y ago
  I think you're right. Curl is a rich source of C era vulnerabilities (memory safety, weak typing, etc.). Anyone using Rust has already decided they don't want anything to do with that.
  - pizlonator 2y ago
    Except when they use `unsafe`, which they do, a lot.
    - Philpax 2y ago
      Can you back up that claim? In my experience, the vast majority of Rust is safe, or built on communally-audited safe abstractions over unsafe code.
      - pizlonator 2y ago
        Using communally audited abstractions over unsafe code means you’re using unsafe a lot. If there was some way to prove that the abstraction is safe, then that would be fine. But the inadequacy of communal auditing is the reason why C has security issues.
        Philpax 2y ago
        The area of Rust code that is unsafe is much, much smaller than the amount in equivalent C code, making it much more tractable to audit. I won't pretend that it's perfect, but it's not remotely comparable to C.
        pizlonator 2y ago
        There’s no easy bound on the set of code you’d have to audit to confirm that even one use of unsafe is in fact safe.
        burjui 2y ago

Hmm, wasn't it the other way round? Curl using a Rust library (hyper) instead of Rust programs using curl? Disclaimer: Just reading TFA, not an active Rust programmer.

pornel 2y ago

Yes, but curl-with-hyper needed Rust programmers to finish and maintain the integration with the C codebase, and couldn't find anyone interested enough, which I assume is because Rust users don't need curl.

aragilar 2y ago
It sounds like a lack of funding (i.e. the grant ran out) was the real issue. Given how high profile curl is, this raises the question of how sustainable rewrite-in-rust efforts driven by grants (or other short-term funding) are, if they don't have an existing rust community to take advantage of the grant.
- pornel 2y ago
  This wasn't a rewrite-in-Rust effort, and I think that's the problem. Nothing valuable from curl has been rewritten in Rust. Only some existing Rust code has been added to curl, but the Rust ecosystem already has a better, safer way of using that code. Curl is not planning to ever require Rust, so the rewrites are limited only to optional components, and can't fully guarantee that the code is safe. The Rust components are required to expose an unsafe unchecked C interface for the rest of curl. C compilers are unable to enforce the safety invariants of the interface, like the Rust compiler would in a program fully written in Rust.
  - aragilar 2y ago
    Probably I misread the original announcement, but I got the impression this was a pilot to adding more rust to curl (and is exactly what a rewrite would start to look like)?
    - pornel 2y ago
      The original announcement explicitly said it's not a rewrite, multiple times: https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyper/ https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp... > A rewrite of curl to another language is not considered > This is not converting curl to Rust. > Don’t be fooled into believing that we are getting rid of C in curl by taking this step. Curl plans to live and die with C: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ This has been reaffirmed recently in https://daniel.haxx.se/blog/2024/08/06/libcurl-is-24-years-old/ https://daniel.haxx.se/blog/2024/08/06/libcurl-is-24-years-o... > There was never any consideration to use another language than C for the library […] Not then, not now. Not only curl is rejecting possibility of being rewritten in Rust, it's also committed to supporting completely-Rust-free curl, because they pride themselves on supporting a lot of retro/niche platforms that Rust doesn't exist on.
IshKebab 2y ago
I think you're right. Curl is a rich source of C era vulnerabilities (memory safety, weak typing, etc.). Anyone using Rust has already decided they don't want anything to do with that.
- pizlonator 2y ago
  Except when they use `unsafe`, which they do, a lot.
  - Philpax 2y ago
    Can you back up that claim? In my experience, the vast majority of Rust is safe, or built on communally-audited safe abstractions over unsafe code.
    - pizlonator 2y ago
      Using communally audited abstractions over unsafe code means you’re using unsafe a lot. If there was some way to prove that the abstraction is safe, then that would be fine. But the inadequacy of communal auditing is the reason why C has security issues.
      - Philpax 2y ago
        The area of Rust code that is unsafe is much, much smaller than the amount in equivalent C code, making it much more tractable to audit. I won't pretend that it's perfect, but it's not remotely comparable to C.
        pizlonator 2y ago
        There’s no easy bound on the set of code you’d have to audit to confirm that even one use of unsafe is in fact safe.
        burjui 2y ago