• @[email protected]
    link
    fedilink
    202 months ago

    As a user of both libcurl (haven’t followed it’s development for years though) and hyper, I’d say either commit to making hyper the default at some point and make that a priority, or drop it altogether. And since there is no intention/plan to do the former, then latter does indeed follow logically.

  • @[email protected]
    link
    fedilink
    English
    -2
    edit-2
    2 months ago

    Hyper doesn’t seem to have a roadmap nor an easy way for newcomers to just pick up stuff and get going. It looks more like a “ready TM” project that’s already hit EOL and is being maintained. Even after reading the blog post I can’t tell what has to be done. There are a bunch issues, but they seem to be a bunch of bugs and refactoring.
    Maybe if it looked more like something that needed help, it would get it?

    Anti Commercial-AI license

    • @[email protected]
      link
      fedilink
      62 months ago

      Hyper isn’t supposed to be what you use if you just want to make a web request or serve some content. You use request and Axum/actix/warp/rocket for that respectively.

      It’s supposed to handle the conversion between bytestream and structs representing http. It is really good at that.

      • @[email protected]
        link
        fedilink
        12 months ago

        To be fair, the latest stable version of hyper until a few months ago (pre v1) did offer usable high level API. What you describe only strictly applies to v1 hyper which hasn’t been around (in stable release form) for long.

        On the other hand, I’m not sure why the parent commentator thinks lack of too much core development is a bad thing, or why they think hyper “needs help”.

    • @[email protected]
      link
      fedilink
      62 months ago

      Hyper itself does work quite well in Rust and is the basis for the vast majority of Rust web frameworks, I just don’t really see a use case for wrapping it in the curl API.