Consider using gleam_time Duration instead of Int for timeouts

[blfpd]

The signature of actor.call is unclear of what magic number to put as the second argument.

pub fn call(
  subject: process.Subject,
  waiting timeout: Int,
  sending make_message: fn(process.Subject(reply)) -> message,
) -> reply

If a reply is not received within the given timeout then the sender process crashes rather than leaving the processes in an invalid state.

As Gleam is a typed language, I would expect a Duration for this kind of value, instead of a undocumented Int that must be in milliseconds.

Alternatives:

• rename the parameter as timeout_ms
• make it clear in the documentation that it expects milliseconds

What do you think?

[lpil]

It could be good for clarity, though it would be a fair bit more verbose to wrap them in duration.milliseconds at every call site.

The main problem here is that it would be a breaking API change, and it would mean that every Gleam project that uses this core package would need to be updated. It would be very disruptive to the ecosystem. We would need to have a very strong motivation to make that cost worthwhile, especially since we have had a lot of churn this year and are looking to minimise it now.

[blfpd]

I totally get it.
It’s just I got bitten by your example code in the ReadMe as I was trying to implement network calls with httpc:

pub fn main() {
  ...

  // Send a message and get a reply
  assert actor.call(actor.data, waiting: 10, sending: Get) == 8
}

and I kept receiving Erlang errors about timeout excedeed without much context.
Obviously 10 ms is fine to add numbers but to get a http response it’s another story. I sincerely thought it is in seconds.