4 ms·

erlang/elixir programmers would disagree -- we match on ad-hoc dynamically typed tuples that serve broadly the same purpose as ADTs all the time, where the only

erlang/elixir programmers would disagree -- we match on ad-hoc dynamically typed tuples that serve broadly the same purpose as ADTs all the time, where the only exhaustiveness you get is the degenerate case ie `_ -> shit_the_bed()` especially common are pattern-matching assignments (technically `=` is the “match operator”) that idiomatically behave much like matches on the left hand side of `<-` in haskell do notation, i.e. inline runtime assertions on structure these communicate programmer intent really well! you could probably have them in static land in a non-`monadFail` context too, but you'd want dependent types or something lest you go the way of typescript and resign yourself to unsoundness in fact it's so nice that i feel pain in any dynamic language without full-fat pattern matching, like when i have to write disgusting if-else chains in complex nix expressions

franz_kafkaagh 4y ago
I write Elixir for work and I love most things about the language. The pattern-matching would still be made better with static checks. It sucks to have a function blow up at runtime because of something as trivial as args being swapped or some code somewhere changing its return types. Someone brought up Gleam earlier, but god why with that syntax? I'd still rather have dynamic checked pattern matching over the alternative.
- 0x69420 4y ago
  dialyzer and a liberal sprinkling of typespecs gets a decent chunk of the way there, meanwhile the problem with gleam and friends is the fact that they're altogether new languages -- the pragmatic solution would be a restricted subset of erlang (that a likewise restricted subset of elixir could comfortably compile down to) where your module has to be fully typed, but you would need some pretty gnarly logics to handle things like "yes, when this function mashes these two iolists together in this way, it's still an iolist" etc
  - franz_kafkaagh 4y ago
    I'm hoping that https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer and its Elixir counterpart get us closer to what "I" want. I find dialyzer often inscrutable compared to something like OCaml's or Haskell's type errors. I do still use it and typespecs, because it's better than no checking.

franz_kafkaagh 4y ago

I write Elixir for work and I love most things about the language. The pattern-matching would still be made better with static checks. It sucks to have a function blow up at runtime because of something as trivial as args being swapped or some code somewhere changing its return types. Someone brought up Gleam earlier, but god why with that syntax? I'd still rather have dynamic checked pattern matching over the alternative.

0x69420 4y ago
dialyzer and a liberal sprinkling of typespecs gets a decent chunk of the way there, meanwhile the problem with gleam and friends is the fact that they're altogether new languages -- the pragmatic solution would be a restricted subset of erlang (that a likewise restricted subset of elixir could comfortably compile down to) where your module has to be fully typed, but you would need some pretty gnarly logics to handle things like "yes, when this function mashes these two iolists together in this way, it's still an iolist" etc
- franz_kafkaagh 4y ago
  I'm hoping that https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer and its Elixir counterpart get us closer to what "I" want. I find dialyzer often inscrutable compared to something like OCaml's or Haskell's type errors. I do still use it and typespecs, because it's better than no checking.