scottswezey
I spent a while implementing Erlang’s :lists.prefix in Elixir today, only I wasn’t aware it existed in Erlang. So now I’m curious if the core team generally accepts PRs that wrap Erlang functionality. I wouldn’t mind contributing some of this “missing” functionality, if the PRs would be considered. Does anyone know? Should I ask the elixir-lang-core mailing list instead?
My arguments for wrapping Erlang functions in Elixir:
- Similar functions, like Elixir’s
List.flatten/2andList.foldl/3,already exist and delegate to Erlang. - It would mostly require rewriting the specs, docs, and tests. That sounds simple enough to me. (But I could be wrong.)
- Documentation in Elixir’s modules is more visible than Erlang’s. I think that is inherently “better,” even though Erlang can be called directly.
The potential downside is maintaining the code, should it ever change in Erlang.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #elixirconf-us
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
Sometimes yes, sometimes no, it depends. In general Elixir try to avoid “plain delegation” to the Erlang modules and unless there is some wrapping/argument reordering/backward compatibility requirements then it is better to just use OTP modules directly (Ockham’s law in practice).
Some of them may be compatibility reasons.
Simple, but brings unnecessary maintenance burden on core team.
I disagree. It is a little bit harder to start, but Erlang documentation is superb resource of knowledge, and with little tooling it is no harder to browse than Elixir documentation (I am talking only about Erlang/OTP docs, not EDoc output which for some reason is completely different).
josevalim
For modules that already exist, we would likely accept such PRs to complement them. For example, the List module started as a complement to Enum for list specific functions and to provide a zero-indexed API. However, if a PR is to add a wrapper for whole new modules, such as
:binaryor:ets, then the answer is likely no exactly because you can use them directly.PS: note in this particular case there is
List.starts_with?/2.scottswezey
Thank you both for letting me know about the PRs policy. It sounds like what I had in mind would be better off as a separate package, if it needs to exist at all.
I can’t believe I missed
List.starts_with?/2.