Hacker News Reader

Comment by yyyk | Hacker News Reader

There are more than a few OpenSSL alternatives. RusTLS is probably not in the lead, not as long as people don't introduce Rust into the base system or their build.

View on HN

> not as long as people don't introduce Rust into the base system

If your base system uses Firefox or ripgrep, Rust is already there.

'Already there' in that case is just 'there's a package for Rust and cargo' (but not necessarily RusTLS). That still leaves a significant integration challenge.

Most (all?) Linux distros (Debian, Arch, Ubuntu, Fedora, ...) use their packaged Rust and cargo to build other packages like Firefox, ripgrep, etc.

Which challenges are not showing up there ? There are packages, and they are usable to build other packages.

1) "I'm using Python/Ruby/Java/C#/some other non-C/C++/Rust language, how do I even call this RusTLS thingy? OpenSSL has shims everywhere so I don't have to worry about FFI/JNI/etc."

2) "My distro does not include a RusTLS package. How do I package this? Do I have to add Rust to my build dependencies now? How do I add the Rust steps to my build system? Where was that CMake manual again..."

Rust has a bright future ahead, but yet another TLS library doesn't justify the overhead and complexity of bringing Rust into a build of non-Rust code. Now, if most distros were to offer a rustls package, this could be entirely different story.

Firefox isn’t exactly fair to include; it has a notoriously complicated build system. Supporting a Firefox build doesn’t necessarily mean that one has general support for Rust.

Sure, but which distro does not package Rust and use the packaged Rust to build Firefox ?

Debian, Ubuntu, Fedora, Arch, ... all do this.

If the Rust displaces C/C++, that introduction could be viewed as an advantage.

Reply on news.ycombinator.com