I suppose I was unclear. It is OTP-style `gen_server` processes that I'm talking about.
> OTP processes communicate via the actor model by sending messages of any type. Each actor is responsible for pattern-matching the incoming message and handling it (or not) based on its type. To implement static typing, you need to know at compile time what type of message an actor can receive, what type it will send back, and how to verify this at compile time.
This is trivial, your `start` function can simply take a function that says which type of message you can receive. Better yet, you split it up in `handle_cast` (which has a well known set of valid return values, you type that as `incomingCastType -> gen_server.CastReturn`) and deal with the rest with interface functions just as you would in normal Erlang usage (i.e. `get_user_preferences(user_preference_process_pid) -> UserPreferences` at the top level of the server).
Here is an example of a process I threw together having never used Gleam before. The underlying `gen_server` library is my own as well, as well as the FFI code (Erlang code) that backs it. My point with posting this is mostly that all of the parts of the server, i.e. what you define what you define a server, are type safe in the type of way that people claim is somehow hard:
import gleam/option
import otp/gen_server
import otp/types.{type Pid}
pub type State {
State(count: Int, initial_count: Int)
}
pub type Message {
Increment(Int)
Decrement(Int)
Reset
}
pub fn start(initial_count: Int) -> Result(Pid(Message), Nil) {
let spec =
gen_server.GenServerStartSpec(
handle_cast:,
init:,
name: option.Some(gen_server.GlobalName("counter")),
)
gen_server.start(spec, initial_count)
}
fn name() -> gen_server.ProcessReference(Message, String) {
gen_server.ByGlobal("counter")
}
pub fn count() -> Result(Int, Nil) {
gen_server.call(name(), fn(state: State) -> gen_server.CallResult(State, Int) {
gen_server.CallOk(new_state: state, reply: state.count)
})
}
pub fn increment(count: Int) -> Nil {
gen_server.cast(name(), Increment(count))
}
pub fn decrement(count: Int) -> Nil {
gen_server.cast(name(), Decrement(count))
}
pub fn reset() -> Nil {
gen_server.cast(name(), Reset)
}
pub fn init(initial_count: Int) -> State {
State(count: initial_count, initial_count:)
}
pub fn handle_cast(
message: Message,
state: State,
) -> gen_server.CastResult(State) {
case message {
Increment(count) ->
gen_server.CastOk(State(..state, count: state.count + count))
Decrement(count) ->
gen_server.CastOk(State(..state, count: state.count - count))
Reset -> gen_server.CastOk(State(..state, count: state.initial_count))
}
}
It's not nearly as big of an issue as people make it out to be; most of the expected behaviors are exactly that: `behaviour`s, and they're not nearly as dynamic as people make them seem. Gleam itself maps custom types very cleanly to tagged tuples (`ThingHere("hello")` maps to `{thing_here, >}`, and so on) so there is no real big issue with mapping a lot of the known and useful return types and so on.