Re:Go channels are bad
by svanderbleek on Wednesday March 02, 2016 @01:49PM
(#11212034)
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.
[ Parent
| on HN ]
Re:Go channels are bad
by im_down_w_otp on Wednesday March 02, 2016 @08:13PM
(#11214370)
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.