Why isn't `:timer` an Elixir module yet?

Welcome! Since 1.17 there’s Kernel.to_timeout/1 which should make calculating milliseconds obsolete

Welcome @Cyytrus!

There is a recent addition to Elixir to turn durations to milliseconds: Kernel — Elixir v1.20.2

Separately, since we can use Erlang functions directly, there’s no need to port things to Elixir unless something is going to be improved in the process (like developer ergonomics)

Besides the other answers: Erlang modules are generally not „ported“ just for the sake of a port existing. You can call erlang modules just fine, please do so. No need for a shallow port. The new to_timeout for example exists to integrate with the new elixir duration definition handling.

There is of course the split of documentation and as such less knowledge of erlang modules. So I do see use in shallow copies.

I agree that’s a real problem and have been bitten by it a good amount of times. But I started seeing it as a “git gud” thing. We can’t constantly duplicate code for surface conveniences. API reshaping, using different contracts, hell, even swapping function argument positions so we can do Elixir pipes, all those are somewhat valid scenarios for introducing shims / wrappers. But just because I or somebody else has not tried to look if Erlang stdlib can help them? I’d say it’s not needed then.

The same can be said about any function in any library. I do not think that “having single place to search for documentation” is valid argument for maintenance burden of wrapping everything.

Ya, seems more like a need for better cross-document searching. Easy to say, harder to do, though. I confess that even though I’m all-for not-shallow wrapping, I almost never think to look in the Erlang docs if I can’t find an Elixir function

For that I highly suggest Dash on macOS (or equivalent like DevDocs.io or Zeal). That provides you offline docs search ad you can add all docs you need.

That I do see use is not to say I advocate for shim libs. After all: where to stop, who keeps them up to date, do we adapt to Elixir conventions, will we use opt lists or maps etc etc.

On the other hand: the need to point to Erlang stdlib it’s not that great. The user suddenly has to know ‘their’ conventions, their doc system and ask questions about it at erlangforums.

Keeping it up to date might not be hard. I checked the commit history of erlang’s timer module, it has 12 commits that change source code for the last 5 years (I’m counting very liberally, spec and doc changes are included). Most of them are tiny.