Thoughts on Ruby’s Net::HTTP

This was written as a non-judgemental comment to a post on lobster.rs (think a smaller version of hackernews).

https://engineering.wework.com/ruby-users-be-wary-of-net-http-f284747288b2

From my experience, Ruby’s Net::HTTP should be avoided if possible. The library is pretty battle-tested in most cases but it can have odd quirks around error handling. Connection issues can raise any number of exceptions and tends to be a leaky abstraction around other networking subsystems.

I know this isn’t necessarily the “ruby way” but I’d much rather have an HTTP library that doesn’t raise exceptions for connection issues, but rather use Go’s pattern of returning an error object. I’d rather reserve exceptions for problems with my code as opposed to external services.

At my last job we were stuck on old versions of libcurl so many other alternatives weren’t possible. I ended up using Excon (pure ruby, not built on Net::HTTP) as a replacement and found it to be much easier to use and far more consistent when our code fell off the happy path.

This all points to a larger issue. The post talks about an HTTP client with extra features that wraps another HTTP client with extra features that wrap a leaky abstraction. Why is all this necessary to make HTTP connections? I get that the point of We::Call is to help developers improve how they make external calls but all of this points to an outdated stdlib (seriously no offense to the folks who work on Net::HTTP).

Why can’t we have a stdlib HTTP client that requires timeouts and is pluggable to use different connection backends (consider this a rhetorical question)? Looking at all the HTTP clients/wrappers in the ruby ecosystem leads me to believe that the stdlib should either be updated or remove in favor of gems that can evolve outside of Ruby’s release cycle.

Evolving ecosystems for modern use-cases is hard. Nothing here is meant to be overly critical or judgemental. Just publishing a brain-dump.