5 ms·

Elixir looks interesting, but coming from many years of using Ruby, another dynamically duck-typed language is the last thing I need, and (in my humble opinion!

Elixir looks interesting, but coming from many years of using Ruby, another dynamically duck-typed language is the last thing I need, and (in my humble opinion!) the last thing I think anyone should need in this day and age. I have been using Go almost exclusively on the backend for the last 18 months or so, and it's a huge safety net. Go is nothing new, of course (it's basically Borland Pascal/Delphi -- which I also used for many years -- with GC), but it brings to the table a strictness that is very much needed (not to mention very good single-core performance). Almost all the problems I encounter in large-scale Ruby programs have to do with wrong types or wrong shapes of data being passed around. It's an antipattern, but we have a lot of code lying around that uses Ruby hashes (dictionaries) instead of classes, because it's easy to do; but even if you create classes to wrap you data and validate the type of every single piece of data you pass around, the surface area is too large to cover perfectly. Not to mention that Ruby suffers from its own icky form of null pointer problem, the nil value. And of course, static typing has many benefits -- not least allowing programmatic introspection (autocompletion, automatic refactoring etc.) in ways dynamic languages will never permit. I know Elixir mitigates the lack of static typing with pattern matching, guards and the possibility of using @spec together with Dialyzer, but I'm not at all convinced that this is sufficient.

yellowapple 10y ago
"another dynamically duck-typed language" Elixir actually has things like behaviours and protocols instead of Ruby-style reliance on duck typing.
ch4s3 10y ago
More importantly, a lot of this is diminished in importance in Elixir by supervisors. Its ok to just let code crash and reset in small chunks in Elixir. Code in Elixir should be structured to take advantage to the ability to crash and recover gracefully.
- lobster_johnson 10y ago
  Well, Ruby will also crash on malformed data; exception handling makes it trivial to recover and continue. Using supervisors to recover by retrying allows you to correct for instability (network faults, oversaturation, locking and such) where a retry might actually fix things. What I am describing is something that cannot be retried in the first place; the next attempt would try to feed the exact same piece of wrongly-typed data back into the supervised process that would then fail again, and so on. Ruby doesn't have anything like OTP, but these are two different problem spaces. Elixir, as far as I can tell, is open to malformed data/types at runtime in exactly the same way that Ruby is.
  - bjz_ 10y ago
    I like failing fast in the exceptional case where things are out of my control, and OTP is a great platform for doing so, but most of the crashes I get in Erlang/Elixir are purely programmer error, and would be trivial to catch statically.
  - dozzie 10y ago
    > Using supervisors to recover by retrying allows you to correct for instability (network faults, oversaturation, locking and such) [...] Using supervisors to retry operations is going to make your system unstable. Supervision tree is not about handling semi-expected faults, it's about starting things at boot time and restarting them in a predictable manner (along with any dependencies) should any of them crash unexpectedly.
    - lobster_johnson 10y ago
      I agree. It was the parent comment that advocated supervisor trees as a way to mitigate runtime type errors.
- zeptomu 10y ago
  It's good to have error recovery built-in, but it does not mean one should take less care of correct code. I believe static typing is just a must for current high-reliability software and going with a dynamic language just seems short-sighted. The remaining languages are mostly JavaScript and Python, but the former survives, as JavaScript is mostly used for UI code and people expect less quality from GUIs and the ladder as it is status-quo for scientific computing and a swiss army knife, as we have so many libraries across so many domains. Dynamic languages are excellent for prototyping (where you keep your constraints in you human head) and errors are not critical. There once was an argument for dynamic languages as they allowed for succinct code, but nowadays modern languages can be correct and succinct code, as we learned to exploit theorems about computation and type theory. [/static hat off]
  - zzzcpan 10y ago
    No, static typing just gives a false sense of reliability to people who are not experts in reliability. There is even some research showing no correlation of static typing vs dynamic typing to bugs [1]. People tend to ignore it though. [1] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
    - zeptomu 10y ago
      > No, static typing just gives a false sense of reliability That is not true, there are real benefits and classes of bugs, that can be avoided before runtime. Historically there was the drawback that inferring these bugs has been computational infeasible for some programs, but nowadays the situation is much better. IMHO the only positive aspect of dynamic languages is their syntactic beauty and existing large eco systems. I admire Elixir's and Erlang's approach to concurrency and think this model (do not share data and engineer for failures that will happen in distributed systems) is great, but could be combined with static typing.
      - goatlover 10y ago
        Dynamic languages tend to let you express yourself more easily and cleanly with less code. Paul Graham years ago wrote about how Lisp let's you write more maintainable code by being able to express yourself close to the problem domain. The power of DSLs is that it's easy to read and write code for that particular sort of task. Another way to state the advantage of expressive languages is that the less code you have to right, the less bugs you will have. And the less code written, the less code needs to be maintained, the less needs to be read to understand what's going on. Of course this all depends on writing clean code, not obfuscated hacks or undocumented messes with needless complexity. But that goes for all programming.
- ryeguy 10y ago
  What? No, not at all. Typing errors are programmer errors and are not recoverable. A supervisor is useful for restarting processes that have intermittent failure, and type-based errors are not an example of that.
goatlover 10y ago
How about Crystal, then? It's largely Ruby syntax with most of it's OOP model, minus some of the metaprogramming. But it's statically typed with a good type inference system, and it's compiled. That way, you get the expressiveness of Ruby (mostly) with the benefits of static compilation. It also has macros to make up for some of the missing metaprogramming.
- danappelxx 10y ago
  But Crystal doesn't run on BEAM, which (I assume!) is something OP was looking for.
  - goatlover 10y ago
    Right, but my post was in response to the one above about how we don't need another dynamic language because a statically typed language like Go is so much better at catching errors. Even though you have to write more code while being restricted in what can be expressed. Thus, Crystal makes sense, best of both worlds, and what not. Of course if you're looking for functional on Beam, then neither Go or Crystal are good comparisons.
- devmunchies 10y ago
  I've been building an app on crystal and really enjoy it but have noticed some of the growing pains as it ramps up to 1.0. Its great but may not quite be ready for production unless you don't mind fixing the occasional breaking changes. Its supposed to hit 1.0 this year.
- lobster_johnson 10y ago
  Yes, Crystal's type inference looks really promising. I hope it will gain enough momentum.
it_learnses 10y ago
Another major point for me is maintainability. When you are trying to figure out the type of the object that was passed in to many layers of functions across files in a legacy codebase, it's a nightmare.
di4na 10y ago
While i really love static typing, saying that Go type system help here is... plain false. Go type system, like its predecessor Java, C and company do not help for that. These are not sound type system. At best they are help for the compiler to decide how to allocate memory or to try to get polymorphism.

yellowapple 10y ago

"another dynamically duck-typed language" Elixir actually has things like behaviours and protocols instead of Ruby-style reliance on duck typing.

ch4s3 10y ago

More importantly, a lot of this is diminished in importance in Elixir by supervisors. Its ok to just let code crash and reset in small chunks in Elixir. Code in Elixir should be structured to take advantage to the ability to crash and recover gracefully.

lobster_johnson 10y ago
Well, Ruby will also crash on malformed data; exception handling makes it trivial to recover and continue. Using supervisors to recover by retrying allows you to correct for instability (network faults, oversaturation, locking and such) where a retry might actually fix things. What I am describing is something that cannot be retried in the first place; the next attempt would try to feed the exact same piece of wrongly-typed data back into the supervised process that would then fail again, and so on. Ruby doesn't have anything like OTP, but these are two different problem spaces. Elixir, as far as I can tell, is open to malformed data/types at runtime in exactly the same way that Ruby is.
- bjz_ 10y ago
  I like failing fast in the exceptional case where things are out of my control, and OTP is a great platform for doing so, but most of the crashes I get in Erlang/Elixir are purely programmer error, and would be trivial to catch statically.
- dozzie 10y ago
  > Using supervisors to recover by retrying allows you to correct for instability (network faults, oversaturation, locking and such) [...] Using supervisors to retry operations is going to make your system unstable. Supervision tree is not about handling semi-expected faults, it's about starting things at boot time and restarting them in a predictable manner (along with any dependencies) should any of them crash unexpectedly.
  - lobster_johnson 10y ago
    I agree. It was the parent comment that advocated supervisor trees as a way to mitigate runtime type errors.
zeptomu 10y ago
It's good to have error recovery built-in, but it does not mean one should take less care of correct code. I believe static typing is just a must for current high-reliability software and going with a dynamic language just seems short-sighted. The remaining languages are mostly JavaScript and Python, but the former survives, as JavaScript is mostly used for UI code and people expect less quality from GUIs and the ladder as it is status-quo for scientific computing and a swiss army knife, as we have so many libraries across so many domains. Dynamic languages are excellent for prototyping (where you keep your constraints in you human head) and errors are not critical. There once was an argument for dynamic languages as they allowed for succinct code, but nowadays modern languages can be correct and succinct code, as we learned to exploit theorems about computation and type theory. [/static hat off]
- zzzcpan 10y ago
  No, static typing just gives a false sense of reliability to people who are not experts in reliability. There is even some research showing no correlation of static typing vs dynamic typing to bugs [1]. People tend to ignore it though. [1] http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
  - zeptomu 10y ago
    > No, static typing just gives a false sense of reliability That is not true, there are real benefits and classes of bugs, that can be avoided before runtime. Historically there was the drawback that inferring these bugs has been computational infeasible for some programs, but nowadays the situation is much better. IMHO the only positive aspect of dynamic languages is their syntactic beauty and existing large eco systems. I admire Elixir's and Erlang's approach to concurrency and think this model (do not share data and engineer for failures that will happen in distributed systems) is great, but could be combined with static typing.
    - goatlover 10y ago
      Dynamic languages tend to let you express yourself more easily and cleanly with less code. Paul Graham years ago wrote about how Lisp let's you write more maintainable code by being able to express yourself close to the problem domain. The power of DSLs is that it's easy to read and write code for that particular sort of task. Another way to state the advantage of expressive languages is that the less code you have to right, the less bugs you will have. And the less code written, the less code needs to be maintained, the less needs to be read to understand what's going on. Of course this all depends on writing clean code, not obfuscated hacks or undocumented messes with needless complexity. But that goes for all programming.
ryeguy 10y ago
What? No, not at all. Typing errors are programmer errors and are not recoverable. A supervisor is useful for restarting processes that have intermittent failure, and type-based errors are not an example of that.

goatlover 10y ago

How about Crystal, then? It's largely Ruby syntax with most of it's OOP model, minus some of the metaprogramming. But it's statically typed with a good type inference system, and it's compiled. That way, you get the expressiveness of Ruby (mostly) with the benefits of static compilation. It also has macros to make up for some of the missing metaprogramming.

danappelxx 10y ago
But Crystal doesn't run on BEAM, which (I assume!) is something OP was looking for.
- goatlover 10y ago
  Right, but my post was in response to the one above about how we don't need another dynamic language because a statically typed language like Go is so much better at catching errors. Even though you have to write more code while being restricted in what can be expressed. Thus, Crystal makes sense, best of both worlds, and what not. Of course if you're looking for functional on Beam, then neither Go or Crystal are good comparisons.
devmunchies 10y ago
I've been building an app on crystal and really enjoy it but have noticed some of the growing pains as it ramps up to 1.0. Its great but may not quite be ready for production unless you don't mind fixing the occasional breaking changes. Its supposed to hit 1.0 this year.
lobster_johnson 10y ago
Yes, Crystal's type inference looks really promising. I hope it will gain enough momentum.

it_learnses 10y ago

Another major point for me is maintainability. When you are trying to figure out the type of the object that was passed in to many layers of functions across files in a legacy codebase, it's a nightmare.

di4na 10y ago

While i really love static typing, saying that Go type system help here is... plain false. Go type system, like its predecessor Java, C and company do not help for that. These are not sound type system. At best they are help for the compiler to decide how to allocate memory or to try to get polymorphism.