fallow gale
I noticed while looking at @naive lodge 's repeatedly repo that it defines handle_info fns where I'd expect handle_cast or handle_call fns (https://github.com/lpil/repeatedly/blob/a47e77ea8c80a174e0e575dc62dce3dbe8dfc7ea/src/repeatedly_ffi.erl#L40-L49). That said, I'm an Erlang noob. Can anyone explain why you'd use erlang:send over gen_server:cast or gen_server:call?
limber patrol
no gen_server in gleam (types, types, types), instead there is gleam/otp/actor
hollow tusk
but this library isnt pure gleam, it FFIs into erlang as you can see in that link
limber patrol
OIC. because there is no reply, there is no need for a call. dunno about cast just remember that Pid ! Msg is (was?) commonly used, which is erlang:send
arctic roost
the way I understand it is that handle_info is for non-request based messages. A request message being one that is an external process trying to interact with the genserver. Therefore you can think of handle_info as internal messages the process sends itself like a timeout. Now that I think of it, I guess it's somewhat analogous to public and private methods. cast and call are meant to be the public interfaces of the process
haughty sage
tick needs to use handle_info, as it’s triggered by erlang:send_after, which will be a message, not a regular OTP cast. Not sure about why handling set_state and replace are implemented that way instead of handle_cast. Would make just as much sense to me for those two to be cast operations.
Main difference between a cast and a regular message send is that cast gives you more options for referencing the gen_server (ie using custom distribution managers like horde/swarm/pg2, registry etc), where as send can only be regular processes.
naive lodge
Honestly I think the send / cast distinction in Erlang is a bit rubbish