I'm not a Erlang guru by any stretch of the imagination. But I would have thought that the privacy that matters the most in Erlang would be the privacy of being able to control what messages you respond to.
That being said, I thought the article was interesting in a pure hacker ethos sense. Like, the article isn't really about function visibility. It's about someone who knows how to do some esoteric things with an esoteric language.
Finally, with respect to Erlang itself. The language feels like it has everything you could possibly want (and this article is an example of that). However, I have always felt that discoverability of these Erlang capabilities has always been not that great. I was trying to do something with Erlang once upon a time (I honestly can't remember what it was) and I was having some trouble. Only to find that, apparently, there was a library that did exactly what I wanted included in the standard libs. With some sort of less than descriptive name. Great times.
Yea, you definitely need to pick through the standard lib to get an idea of what's there. Learned that lesson the hard way with Elixir when I tried to ignore all the Erlang stuff initially.
> However, I have always felt that discoverability of these Erlang capabilities has always been not that great.
I think the main reason is that the docs of stdlib are split between a number of "applications" (in OTP sense) and that there's no index of all the modules in one place (or I couldn't find one). So, starting here: https://www.erlang.org/docs/24/applications.html you need to open at least erts, kernel, and stdlib in separate tabs, and remember to search in all 3 for even basic things. And that's just library reference - there's also manual for Erlang, OTP, and many of the applications. Fortunately, manual and reference of the same app are often interlinked.
This isn't super surprising. For all the Erlang I've used, I always had access to the source, so it'd be simple enough to modify the source (either directly, or through a code transformation), to get access to the nice function I want... it's kind of neat that you can decompile the beam files (at least if debug_info is present) and recompile with different options; and of course, being able to hot load (almost) everything is neat too.
8 comments
[ 0.19 ms ] story [ 32.8 ms ] threadThat being said, I thought the article was interesting in a pure hacker ethos sense. Like, the article isn't really about function visibility. It's about someone who knows how to do some esoteric things with an esoteric language.
Finally, with respect to Erlang itself. The language feels like it has everything you could possibly want (and this article is an example of that). However, I have always felt that discoverability of these Erlang capabilities has always been not that great. I was trying to do something with Erlang once upon a time (I honestly can't remember what it was) and I was having some trouble. Only to find that, apparently, there was a library that did exactly what I wanted included in the standard libs. With some sort of less than descriptive name. Great times.
I think the main reason is that the docs of stdlib are split between a number of "applications" (in OTP sense) and that there's no index of all the modules in one place (or I couldn't find one). So, starting here: https://www.erlang.org/docs/24/applications.html you need to open at least erts, kernel, and stdlib in separate tabs, and remember to search in all 3 for even basic things. And that's just library reference - there's also manual for Erlang, OTP, and many of the applications. Fortunately, manual and reference of the same app are often interlinked.
Whether it’s a good idea to test private functions is a whole different issue…