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
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
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
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
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.