[derefr]

It actually might. You can write Elixir for years without learning Erlang syntax, but if you’re a perfectionist, you’re gonna notice bugs in your Erlang deps just as much as in your Elixir deps, and you’re gonna want to submit PRs for them, and that leads you to learning Erlang.

Also, IMHO, if you want to have a solid foundation when learning Elixir, it’s simpler to learn Erlang/OTP as a cohesive whole (from e.g. ferd’s Learn You Some Erlang book) and then “chase it” with an Elixir book; rather than trying to understand OTP through the lens of how it’s exposed in Elixir. Everyone in the elixir-lang Slack that asks how to get started learning Elixir, I tell them to learn Erlang first. So “being a simpler jumping-off point to Elixir knowledge” is also kind of a killer app.

I would guess that this is only true in cases where there are killer apps for a secondary language on a runtime, but no killer apps for the primary language. Like, I wouldn’t say that Clojure is a killer app for Java. But then, is that because Java is already popular? Or is that because Clojure developers don’t necessarily end up knowing Java as well as Elixir developers end up knowing Erlang?

[andrenth]

There's a lot in the Erlang stdlib that is not available in a wrapped form from Elixir's. As of now I think you need to know at least a bit of Erlang (e.g. to understand the stdlib docs) to be able to use Elixir more productively.

I'm not sure if Elixir developers plan on providing complete wrappers for Erlang's stdlib in the future. This is in fact one criticism I have of the language, because even for simple things like serialization you have to drop to Erlang and call :erlang.term_to_binary(), which feels a bit second-class.

I really like the language otherwise though.

[klibertp]

> 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 :)

[andrenth]

I agree, but my point wasn't about the erlang module specifically. Maybe :ets would have been a better example.

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 :)

[klibertp]

> I still think it's a good idea

Hm, it definitely looks like it. What arguments against it were raised?

[andrenth]

IIRC the main one is that it could be confusing inside a list, e.g. [foo: bar] vs [foo:bar()]. Someone also mentioned that `foo. bar()` (with a space after the dot) is legal syntax, but `foo: bar()` wouldn't be.

I guess you can always do `alias :foo, as: Foo`.