3 ms·

Not very helpful. Interestingly, coming to Elixir from another dynamically typed language (Python), I tend to do much fewer runtime/typing errors than ever bef

Not very helpful. Interestingly, coming to Elixir from another dynamically typed language (Python), I tend to do much fewer runtime/typing errors than ever before. I might be more experienced, or the tooling and compiler are good enough to catch the most common bugs. I get a few "no matching clause" with my data ingestion tool on my Sentry log because external APIs are flaky and a cosmic ray flipped a bit so that I'm reading incorrect data. A GenServer somewhere crashes, restarts and the data comes back clean, without any user disruption at all.

keithnoizu 7y ago
The only part I miss about erlang is it being a little harder to shoot your self in the foot with types.
phtrivier 7y ago
As you might have guess, absolutely not my experience at all. But as explained otherwise, I'm in situation where "bad" data just keep coming in (and "bad" just mean "data that exercises a path were a runtime error will happen because of a typo that the compiler did not catch.) So "let it crash" means "let it crash again", and I don't see the obvious solution... But again, I'm completely ready to hear that it's just my setup, or how we failed to build the app. Just wanted to confirm that it's completely possible to shoot yourself in the foot, which I'm surprised hardly anyone mention when talking about elixir. Anyone interested should give it a try.
- Supermancho 7y ago
  There are OTP strategies that are a "do not recover from crash", or more to your case "do not recover more than N times per Z timeslice". http://erlang.org/doc/design_principles/sup_princ.html#maximum-restart-intensity http://erlang.org/doc/design_principles/sup_princ.html#maxim...
- m45t3r 7y ago
  I think in this case having bad input is part of your business logic and should be treated as such. This is very easy in Elixir, specially since you can overload a function using pattern matching and so you can create a function (defined after all others) that matches anything. This is basically your error case. "Let it crash" is commonly misunderstood. It doesn't mean that you shouldn't treat the known unknown cases of your business (like bad input), it means errors that are generally not known a prior (a database crash or network partition, for example) does not need to have a treatment since the Elixir/Erlang will simple crash and restart. Things like K8s also brings a similar thing that Elixir brings to you, however having this in language is powerful since it allows ulyou to treat it better, if you want.
- pdimitar 7y ago
  You can shoot yourself in the foot with every language. Your comments read like "but I was promised magic and I found no magic" to me. Well, of course there's no magic. What there is is a really good runtime and a good tooling that allows you to avoid some mistakes preliminarily.
- elcritch 7y ago
  I’d say it’s not really different than other dynamic languages in that you can get those runtime errors. Initially I got lots of those but after getting a bit of experience I hardly get them anymore aside from initial kinks after refactoring. Maybe try VS Code with the Elixir LS plugin. It runs dialyzer automatically and highlights errors which also catches a ton of those runtime type issues. It’s pretty nice, often more expressive than standard typed languages.

keithnoizu 7y ago

The only part I miss about erlang is it being a little harder to shoot your self in the foot with types.

phtrivier 7y ago

As you might have guess, absolutely not my experience at all. But as explained otherwise, I'm in situation where "bad" data just keep coming in (and "bad" just mean "data that exercises a path were a runtime error will happen because of a typo that the compiler did not catch.) So "let it crash" means "let it crash again", and I don't see the obvious solution... But again, I'm completely ready to hear that it's just my setup, or how we failed to build the app. Just wanted to confirm that it's completely possible to shoot yourself in the foot, which I'm surprised hardly anyone mention when talking about elixir. Anyone interested should give it a try.

Supermancho 7y ago
There are OTP strategies that are a "do not recover from crash", or more to your case "do not recover more than N times per Z timeslice". http://erlang.org/doc/design_principles/sup_princ.html#maximum-restart-intensity http://erlang.org/doc/design_principles/sup_princ.html#maxim...
m45t3r 7y ago
I think in this case having bad input is part of your business logic and should be treated as such. This is very easy in Elixir, specially since you can overload a function using pattern matching and so you can create a function (defined after all others) that matches anything. This is basically your error case. "Let it crash" is commonly misunderstood. It doesn't mean that you shouldn't treat the known unknown cases of your business (like bad input), it means errors that are generally not known a prior (a database crash or network partition, for example) does not need to have a treatment since the Elixir/Erlang will simple crash and restart. Things like K8s also brings a similar thing that Elixir brings to you, however having this in language is powerful since it allows ulyou to treat it better, if you want.
pdimitar 7y ago
You can shoot yourself in the foot with every language. Your comments read like "but I was promised magic and I found no magic" to me. Well, of course there's no magic. What there is is a really good runtime and a good tooling that allows you to avoid some mistakes preliminarily.
elcritch 7y ago
I’d say it’s not really different than other dynamic languages in that you can get those runtime errors. Initially I got lots of those but after getting a bit of experience I hardly get them anymore aside from initial kinks after refactoring. Maybe try VS Code with the Elixir LS plugin. It runs dialyzer automatically and highlights errors which also catches a ton of those runtime type issues. It’s pretty nice, often more expressive than standard typed languages.