3 ms·

I use to think the same, then I tried Elixir. It made me realize the language ecosystem can outweigh cons as big as not having types. The Elixir ecosystem is t

I use to think the same, then I tried Elixir. It made me realize the language ecosystem can outweigh cons as big as not having types. The Elixir ecosystem is top notch. Phoenix, Ecto, Livebook, Mix, Hex, Nx, Axon, Scholar, Explorer, Broadway, and Rustler are libraries and tools that make it hard to use anything else even when the language doesn't have types. I never enjoyed programming in a language more than Elixir. Tho, they are currently are in the process of researching a type system for Elixir.

s6ro 3y ago
Elixir is functional and immutable first, (and structs) - that alleviates somewhat the pain of not having a strong type system. I really like the architecture of OTP, but I still find myself using Elixir in anger. Especially, if I'm trying to bring and old(er) codebase (Elixir 1.9) up to the newest release... and upgrading packages, checking if things are likely to brake etc. I constantly find myself realising that I cannot trust the compiler, which means more defensive coding, more tests, more time spent... As an example, upgraded postgrex. The return tuple of one its functions had changed from 2 elements to 3 elements. Did the compiler caught it? No. Had I had dialyzer type spec-s on my private function, I would at least gotten a warning. Thus, morale of the story: always type spec even your private functions , especially if they use 3rd party code.
datadeft 3y ago
{:ok, x} | {:err, y} is my favorite pattern. You can make sure that the caller handles both cases, the ok case and the error case. What you put in y is up to you. If you have dependencies you can decide the bubble up error or return something that you want. We have a bigger system in Elixir and it was trivial to write the correct implementation for exponential backoff to interact with the outside word (calling lots of external services that sometimes time out). With Python this is not as trivial because Guido hates pattern matching and you have catch exceptions and do if else a lot. With Elixir I see immediately while developing if I left out a case. With Python I see it in production when we crashed.

s6ro 3y ago

Elixir is functional and immutable first, (and structs) - that alleviates somewhat the pain of not having a strong type system. I really like the architecture of OTP, but I still find myself using Elixir in anger. Especially, if I'm trying to bring and old(er) codebase (Elixir 1.9) up to the newest release... and upgrading packages, checking if things are likely to brake etc. I constantly find myself realising that I cannot trust the compiler, which means more defensive coding, more tests, more time spent... As an example, upgraded postgrex. The return tuple of one its functions had changed from 2 elements to 3 elements. Did the compiler caught it? No. Had I had dialyzer type spec-s on my private function, I would at least gotten a warning. Thus, morale of the story: always type spec even your private functions , especially if they use 3rd party code.

datadeft 3y ago

{:ok, x} | {:err, y} is my favorite pattern. You can make sure that the caller handles both cases, the ok case and the error case. What you put in y is up to you. If you have dependencies you can decide the bubble up error or return something that you want. We have a bigger system in Elixir and it was trivial to write the correct implementation for exponential backoff to interact with the outside word (calling lots of external services that sometimes time out). With Python this is not as trivial because Guido hates pattern matching and you have catch exceptions and do if else a lot. With Elixir I see immediately while developing if I left out a case. With Python I see it in production when we crashed.