Is creation of erlang wrappers in elixir evil?

Recently I had to refactor a system that uses SFTP for copying files. By default the project was using the sftp_ex library. Now, when I wanted to use the library, there were a lot of gaps in documentation. After looking at source code, I noticed that most of the functionality is taken from ssh_sftp and ssh, basically a wrapper with some additional utility functions.

Now, if you open erlang documentation for ssh_sftp, you can see how clear and detailed the features are documented. The only downside of reading erlang documentation is that you should know that elixir string are not compatible with keyword lists, that are defined in erlang as strings and that lowercase keys in erlang are treated as atoms in elixir.

Moreover, the library has to stay in active maintenance, since ssh and ssh_sftp are shipped with erlang, so they are bound to change in newer OTP versions and currently mix does not support locking/checking libraries shipped with OTP. What everybody does is forking the library and implementing their own features, making a huge range of possible buggy/undocumented libraries.

This is just one of the libraries, there will be more and more libraries like this one around, what do you think would be the solution to this problem?

1 Like

it’s generally considered “bad form” to just make an erlang wrapper unless you have something “opinionated” to bring back to the ecosystem.

Todd Resudek made a good opinion piece on this: It's time to embrace Erlang - TODD RESUDEK - YouTube

I have some personal examples of libraries that I made that I consider to be "sufficiently opinionated’, too.

7 Likes