What does HackerNews think of libhydrogen?

A lightweight, secure, easy-to-use crypto library suitable for constrained environments.

Language: C

#34 in C
#8 in Java
This seems extremely similar to https://github.com/jedisct1/libhydrogen -- X25519 and Gimli. (well, and the name...). It also appears to pull from its test suite and aim for compatibility in some ways.
Tossing everything into a single file is not required.

You can use includes to have "a single file to add to the project", and still split your code in smaller, readable files.

See https://github.com/jedisct1/libhydrogen for example. It's a single-file crypto library from an application perspective, but everything was not stored into a single, hard-to-navigate file.

In the same vein: libhydrogen [1].

Both the API and the underlying primitives are still moving targets, but one of the motivations behind this project was to revisit the NaCl/LibSodium/SUPERCOP API to build something more difficult to misuse.

In particular, users never provide nonces. Contexts are mandatory everywhere. A broken PRG is not always catastrophic. Operations requiring keys have a dedicated keygen() function (eventually, keys may have their own type instead of generic byte buffers). There's no crypto_stream_* API, but a randombytes_buf_deterministic() function.

libhydrogen is not meant to replace libsodium, but the libsodium2 API may resemble more to it than the current one.

[1] https://github.com/jedisct1/libhydrogen