It "just works" in Go too, minus immutability, but congrats on your technology decision. You don't get type checking but c'est la vie.

Save the following code in "someone_was_wrong_on_the_internet.erl" and then run "dialyzer --src someone_was_wrong_on_the_internet.erl"

  -module(someone_was_wrong_on_the_internet).
  -export([init/0, fizzbuzzer/1]).
  
  -spec init() -> list(pos_integer() | binary()).
  init() ->
      List = [-1, 0, 0.1, 1, 2, 3, 5, 15, 2, 3, 5, 15, 1],
      [fizzbuzzer(Result) || Result <- List].
  
  -spec fizzbuzzer(pos_integer()) -> pos_integer() | binary().
  fizzbuzzer(Number) when Number rem 15 =:= 0 ->
      <<"FizzBuzz">>;
  fizzbuzzer(Number) when Number rem 5 =:= 0 ->
      <<"Buzz">>;
  fizzbuzzer(Number) when Number rem 3 =:= 0 ->
      <<"Fizz">>;
  fizzbuzzer(Number) ->
      Number.

Dialyzer will fail the type check until you remove [-1, 0, 0.1] from the list. Not with a particularly helpful error, but it does fail it nonetheless.

The code itself is a valid program that runs, but it produces incorrect output, because 0 rem 15 =:= 0, so you get <<"FizzBuzz">> where you'd expect to get a 0 in the list. By running Dialyzer in my build chain I can catch that my implementation doesn't match my constraints at compile-time. In a way that I otherwise would have only found at runtime.

Though while creating this little pointless example one thing I'm not super clear on is why Dialyzer fails to notice that my return type from

  fizzbuzzer(Number) ->
      Number.

if I change it to

  fizzbuzzer(Number) ->
      -Number.

will return a neg_integer() and fail to satisfy the return spec. Despite that I've told it the input must be a be a pos_integer(). Unless I enable the -Wspecdiffs flag, in which case it notices the problem.

Dialyzer

Restricting input based on type hierarchies can reduce a certain class of bugs, yes, but careful use of guards as well as typespecs and unit test coverage (which you should have, anyway) can accomplish much of what type restrictions can

Was something I said factually wrong? User im_down_w_otp put up an example of what I'm talking about (minus the unit testing) so what gives?

I suspect dismissing static typing whole cloth with "unit tests and certain guards can give you most of the benefits" comes off badly to some people.

I don't see how "can accomplish much of what type restrictions can" is the equivalent of "dismissing static typing whole cloth"

I choose wording carefully for a reason