hyper is a protective and efficient HTTP library for all.
Tenets are guiding principles. They guide how decisions are made for the whole project. Ideally, we do all of them all the time. In some cases, though, we may be forced to decide between slightly penalizing one goal or another. In that case, we tend to support those goals that come earlier in the list over those that come later (but every case is different).
hyper is open source, always. The success of hyper depends on the health of the community building and using it. All contributions are in the open. We don’t maintain private versions, and don’t include features that aren’t useful to others.
We prioritize kindness, compassion and empathy towards all contributors. Technical skill is not a substitute for human decency.
It’s not usually hard for an open source library to stay open and also meet its other priorities. Here’s some instances where being Open would be more important than Correct or Fast:
Say an individual were to bring forward a contribution that makes hyper more correct, or faster, perhaps fixing some serious bug. But in doing so, they also insulted people, harassed other contributors or users, or shamed everyone for the previous code. They felt their contribution was “invaluable”. We would not accept such a contribution, instead banning the user and rewriting the code amongst the kind collaborators of the project.
Say someone brings a contribution that adds a new feature useful for performance or correctness, but their work accomplishes this by integrating hyper with a proprietary library. We would not accept such a contribution, because we don’t want such a feature limited only to those users willing to compromise openness, and we don’t want to bifurcate the ecosystem between those who make that compromise and those who don’t.
hyper is a memory safe and precise implementation of the HTTP specification. Memory safety is vital in a core Internet technology. Following the HTTP specifications correctly protects users. It makes the software durable to the “real world”. Where feasible, hyper enforces correct usage.
This is more than just “don’t write bugs”. hyper actively protects the user.
- Even though we follow the HTTP/* specs, hyper doesn’t blindly implement everything without considering if it is safe to do so.
A fast experience delights users. A faster network library means a faster application, resulting in delighting our users’ users. Whether with one request, or millions.
Being fast means we improve throughput, drive down CPU usage, and improve sustainability.
Fast enough. We don’t sacrifice sanity for speed.
hyper is specifically focused on HTTP. Supporting new HTTP versions is in scope, but supporting separate protocols is not.
This also defines what the abstraction layer is: the API is designed around sending and receiving HTTP messages.
hyper enables as many usecases as possible. It has no opinion on application structure, and makes few assumptions about its environment. This includes being portable to different operating systems.
- While we choose safer defaults to be Correct, hyper includes options to allow different behavior, when the user requires them.
- Providing choice usually makes things more complex, so being Flexible does mean it’s less easy. That can sometimes conflict with simplest way of making hyper Understandable.
hyper is no more complicated than it has to be. HTTP is not simple. It may not be as “easy” as 1-line to do everything, but it shouldn’t be “hard” to find the answers.
From logical and misuse-resistant APIs, to stellar documentation, to transparent metrics.