Add process names, refocus scope, rework API

[lpil]

Reworking the API of this package for a v1 release! The big new feature is named processes, which will make writing OTP programs much easier in Gleam.

[bcpeinhardt]

General note: There's a lot of really good QOL stuff happening in this PR :)

[bcpeinhardt]

Made a small PR with some minor docs changes so you don't have to bother copying them over: #72

[rawhat]

i like these changes. RIP rescue 🙏🏻

[sbergen]

Since we're introducing breaking changes, would it make sense to include #67 also? It contains changes from String to Dynamic, and Dynamic to ExitReason.

I can rebase it on top of this branch, if it helps.

[lpil]

Good idea @sbergen! I wonder if there's any further improvements we could make to those types...

[sbergen]

Good idea @sbergen! I wonder if there's any further improvements we could make to those types...

I still find the asymmetry of send_abnormal_exit using String somewhat complicated and restrictive. Would rather have a more symmetric send_exit(Pid, ExitReason). Being more symmetric makes things easier to think about (for me, at least), and being able to send a decodable value as an exit reason can be useful. If we also added exit(ExitReason) we'd be more in line with the Erlang exit/1 and exit/2 semantics, as far as I can see.

[lpil]

What are some uses you have for decoding the exit reason?

If we also added exit(ExitReason) we'd be more in line with the Erlang exit/1 and exit/2 semantics, as far as I can see.

This would mean we have it completely unchecked by the type system, and the programmer just have to get the correct magic values!

[lpil]

OK, I am convinced @sbergen ! I have merged your changes into this branch. :)

[sbergen]

It sounds like a mistake to me to be using non-local error handling in such a fine-grained way.

As a package author, I was thinking of it more as a HTTP 500 (oops, my bad) vs 502 (I can't do my job because of a third party) that could be reported to the user of the package...

The message is a debug convenience rather than a tool for exception based flow control, the same as the text message one can give to a panic.

...but indeed, this sort of information could be included in strings also. I just like types a lot more than strings :)

...and exits are not typable as they can originate from outside of Gleam, just like exceptions.

I think you could have one typed variant of ExitReason, but especially if we don't want to encourage using exit values, I don't think it's really an avenue worth pursuing.

OK, I am convinced @sbergen ! I have merged your changes into this branch. :)

send_abnormal_exit still takes a string, but I think as long as Abnormal holds Dynamic, it will make using dynamic exit values with FFI for those who really want to do it easy enough 👍

[rawhat]

🙏🏻 extremely excited