|
> you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class. Well, to be honest, :erlang module has many functions, many of which have literally nothing in common with each other. That's because that module is imported by default in Erlang - it's like `__builtins__` in Python. Exposing it as `Erlang.term_to_binary/1` module/wrapper wouldn't really fit well with the rest of the Elixir stdlib, which is (commendably) very neatly organized, with each module doing just what its name suggests. On the other hand, wrapping just `erlang:term_to_binary/1` and `erlang:binary_to_term/1` in a `Serializer` module would be probably ok, but then there are tens of such modules you'd be pressed to implement for `:erlang` alone, and it gets worse with a rather extensive Erlang stdlib and OTP apps. One of the Elixir selling points was (and probably is) the simplest possible FFI to (and back from) other BEAM languages (like Erlang or LFE). Calling an Erlang function is exactly the same operation as calling Elixir one - literally, the only difference is that, syntactically, most Elixir functions live in CapitalizedModules. That's it - there's no runtime overhead, no difference in handling arities, arguments, guards, exceptions or return values. The feeling of second-classiness is definitely there - the argument order and naming conventions (for args and functions both) differ, and the Erlang/OTP docs (used to - not sure it's still the case) look less than appealing in comparison with Elixir. But, realistically, Erlang's stdlib is a result of 30 years of accretion of tools and it's not small by any means. Wrapping entirety of it would take many years at least and it would consume a lot of developers' time, possibly hindering the development of the language itself. Elixir is still a young language, without a very large following and secure position in the industry - it's dangerous to divide your forces and pursue to many goals at once in a situation like that. To summarize: in my opinion, the feeling of second-classiness is not a serious enough problem to invest resources in making it go away, at least at this point. While they may look less than pretty, Erlang/OTP docs are very well written and the functionalities tend to be rock solid. The stdlib is... not the prettiest in terms of organization, owing to decades of evolution, but with the FFI as trivial as it is, it's more than usable from Elixir. I think that was the original plan: the stdlib of Elixir was intentionally kept small and very clean, which was supposed to be Elixir's appeal, but it's only possible if reaching for the functionality missing from stdlib is simple. Just a hunch of mine, we'd need to ask Jose to know for sure :) |
At one point I suggested in the forums that, inspired by how Elixir understands [foo: bar] as equivalent to [{:foo, bar}], maybe it could allow foo:bar() as equivalent to :foo.bar(). That would make the syntax exactly like Erlang's, which would be pretty nice to signal "I'm calling an Erlang function here".
I still think it's a good idea, but it wasn't met with a lot of enthusiasm :)