This is something that was on my mind for some time now. We have the situation repeating that I saw in Ruby ecosystem as well, where it hasn’t been exactly solved: I end up with projects having dependencies on multiple HTTP client libraries.
The reason behind people wanting to use third party library in first place, is that it requires significant legwork to get it done right using standard Erlang standard library: if you want ssl, gzip, redirects etc. It also does not feel exactly Elixir idiomatic to use it.
So developers pick up whatever library they feel is slightly better/faster to use out of the box. I understand that making HTTP requests only looks like simple task, and in fact is a complex scenario that varies from use case to use case, but having a decent, easy to use HTTP client in standard library would bring in many benefits:
we can reduce dependencies on our projects
we have central place to control/monitor/rate limit/stub HTTP requests we’re making
we have a number of expected errors/exceptions that we can expect to happen, esp. when third party API wrappers do focus on happy paths only
I don’t see any intrinsic value in making it part of the standard library. The only thing that would be reduced is the amount of explicit dependencies, but using it would still incur the same cost anyway.
What is it you imagine will be better about point 2 and 3 with regards to a standard lib offering? I don’t see how it’ll be any different than pulling in a good dependency (HTTPoison, for example) and using that. There’s nothing privileged about modules that are shipped with the standard distribution.
Including in stdlib, has a huge consequence that is generally ignored - it has to be maintained from that point onwards by the core team. There’s only so much time in a day, so ultimately this means less maintenance for other parts of stdlib.
The bigger problem is that there’s no clear winner in terms of an http library with a good interface (by good interface, I mean a composable one).
My point was that from a technical standpoint no module that is included in the standard distribution is privileged; it’s a module like any other. As such, it won’t matter that it’s in the standard distro.
The main problem I see with bringing one of existing Elixir HTTP clients as one into standard library is actually related to that. The clients I saw rely not on standard httpc client, but use third party libraries. So we have third party Elixir library, pulling third party Erlang library, to do HTTP requests.
HTTPosion is a total disaster. After 25,000,000,000 requests in last few months and looking up for internal structure of hackney and the lib, I concluded that this lib stops working (even simple get requests). I replaced whole code with Tesla and everything worked.
I couldn’t find single piece of useful error code but “connection error”.
If you don’t like the one included in Elixir, it’d be a lot of work for the core team to maintain even more which time constraints limit the ability to do, why not use a third-party one or write your own?