5 ms·

You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because i

You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because it is statically typed. You can read more about pros and cons of statically and dynamically type languages [1] [1] http://programmers.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing http://programmers.stackexchange.com/questions/122205/what-i...

josevalim 11y ago
The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime. Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...). I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting. Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.
- niklasni1 11y ago
  > The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems compared to C which lacks e.g. generics and proper sum types. That said, I find Elixir very interesting for the exact reasons you said.
  - Scarbutt 11y ago
    They're both statically typed, but the type systems obviously aren't equal. That was his point.
    - niklasni1 11y ago
      I suppose the main difference is the presence of algebraic data types. But does that even make sense without static typing?
- namelezz 11y ago
  Thank you for sharing. Hopefully, learning Elixir will be a great experience for me.
rubiquity 11y ago
I've used both Go and Elixir so here's my thoughts: Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time. Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't. As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang. If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].
- bpicolo 11y ago
  You can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.
  - 15155 11y ago
    Due to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc. It's an entirely different level of statically-verifiable correctness.
    - bpicolo 11y ago
      I know of class/instance variables working for py linters. Dynamically-defined methods, no, but those are hard to reason about even for humans so it's best to avoid them entirely.
davelnewton 11y ago
I've heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.
- niklasni1 11y ago
  Having worked with Scala a lot recently, I've found that the ability to turn logic issues into type issues is an incredible gain for my productivity. OCaml programmer Yaron Minsky summed it up nicely with the advice that you should "make illegal states unrepresentable". He gives a good example of modelling a network connection in [0]. Another example is instead of shuffling a bunch of bare UUID objects around (or strings, for that matter) in a system where lots of different things have a UUID, I can make a simple reference type for the IDs of different entities. This way, calling a function that takes the UUID of one type of entity with that of another can be a type error that's caught by the compiler instead of a logic error that's caught by a unit test. This is cumbersome at best to do in Java or C, and obviously impossible in Python or Ruby, but in ML-inspired languages it's simply the most natural way to work. [0] https://vimeo.com/14313378 https://vimeo.com/14313378
  - davelnewton 11y ago
    I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".
    - fghfghgfhfg 11y ago
      The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it. It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to change to account for expanded functionality or whatever, you again pay some cost in complexity, but in return every place the new type would cause problems you get a nice error. The other thing to keep in mind is that whether or not these type are codified in the language they're there conceptually. Just because you have to write them down doesn't necessarily add complexity but is more like forced documentation that can be used to eliminate who classes of problems. It's difficult to see how this wouldn't intrinsically be better than so-called dynamic typing.
bbatha 11y ago
Elixir can be optionally typed with the Dialyzer which will bring you to about the same level of static typing as go (if not more because the dialyzer allows for generics).
- flackjap 11y ago
  With compile time checking that is already there + Dialyzer, you basically have the whole 'code correctness' side of static typing? Right?

josevalim 11y ago

The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime. Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...). I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting. Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.

niklasni1 11y ago
> The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development? They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems compared to C which lacks e.g. generics and proper sum types. That said, I find Elixir very interesting for the exact reasons you said.
- Scarbutt 11y ago
  They're both statically typed, but the type systems obviously aren't equal. That was his point.
  - niklasni1 11y ago
    I suppose the main difference is the presence of algebraic data types. But does that even make sense without static typing?
namelezz 11y ago
Thank you for sharing. Hopefully, learning Elixir will be a great experience for me.

rubiquity 11y ago

I've used both Go and Elixir so here's my thoughts: Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time. Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't. As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang. If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].

bpicolo 11y ago
You can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.
- 15155 11y ago
  Due to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc. It's an entirely different level of statically-verifiable correctness.
  - bpicolo 11y ago
    I know of class/instance variables working for py linters. Dynamically-defined methods, no, but those are hard to reason about even for humans so it's best to avoid them entirely.

davelnewton 11y ago

I've heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.

niklasni1 11y ago
Having worked with Scala a lot recently, I've found that the ability to turn logic issues into type issues is an incredible gain for my productivity. OCaml programmer Yaron Minsky summed it up nicely with the advice that you should "make illegal states unrepresentable". He gives a good example of modelling a network connection in [0]. Another example is instead of shuffling a bunch of bare UUID objects around (or strings, for that matter) in a system where lots of different things have a UUID, I can make a simple reference type for the IDs of different entities. This way, calling a function that takes the UUID of one type of entity with that of another can be a type error that's caught by the compiler instead of a logic error that's caught by a unit test. This is cumbersome at best to do in Java or C, and obviously impossible in Python or Ruby, but in ML-inspired languages it's simply the most natural way to work. [0] https://vimeo.com/14313378 https://vimeo.com/14313378
- davelnewton 11y ago
  I wouldn't classify those as "type problems" but rather "using types to solve problems". I have no issue with the claim that great type systems make some... ahem... types of problems go away, although it's often trading one type of complexity for another. My issue is with the claim that "long term development is intrinsically better with static typing".
  - fghfghgfhfg 11y ago
    The type system, at least more powerful ones, encode a lot of intention and more importantly, enforce it. It might add some additional complexity in the first writing of the code, but in return you eliminate whole classes of problems forever. It's not just the initial writing that benefits (at some cost, admittedly), but all future changes won't have those problems either. In the case the types themselves need to change to account for expanded functionality or whatever, you again pay some cost in complexity, but in return every place the new type would cause problems you get a nice error. The other thing to keep in mind is that whether or not these type are codified in the language they're there conceptually. Just because you have to write them down doesn't necessarily add complexity but is more like forced documentation that can be used to eliminate who classes of problems. It's difficult to see how this wouldn't intrinsically be better than so-called dynamic typing.

bbatha 11y ago

Elixir can be optionally typed with the Dialyzer which will bring you to about the same level of static typing as go (if not more because the dialyzer allows for generics).

flackjap 11y ago
With compile time checking that is already there + Dialyzer, you basically have the whole 'code correctness' side of static typing? Right?