3 ms·

While I greatly appreciate elixir it is completely malplaced to contrast fault tolerance and type systems - they solve very different needs. As such fault tole

While I greatly appreciate elixir it is completely malplaced to contrast fault tolerance and type systems - they solve very different needs. As such fault tolerance does not guarantee that you MRI scanner does not kill your patients. You likely want both.

throwawaymaths 1y ago
no, but effort is a finite resource so it justifies why they didn't bother.
- tossandthrow 1y ago
  Well, the people behind elixir seems to have accepted that typing is necessary. I see this story on an on: some hacker makes a language, they hate types because they want to express themselves. The languages gets traction. Now enterprise application and applications with several devs use it and typing gets essential - types will then gradually be added.
  - throwawaymaths 1y ago
    sure, a few years behind typescript/mypy isnt really so bad for a language without a microsoft or a google behind it, is all im saying.
    - tossandthrow 1y ago
      > isnt really so bad for a language without a microsoft or a google behind it, is all im saying What? Elm was literally the result of a single grad students side project - elm incorporates both a sound type system and FRP. This has nothing to do with time. It was a decision not to support it.
      - throwawaymaths 1y ago
        sure part of the decision is that you can't really soundly type (in a developer sanity preserving way) across a cluster that runs multiple versions of software (which is a real use case that the authors absolutely needed to support as part of the core business). but they let dialyzer in to the core so it's not like the team was actively hostile to typing.
        tossandthrow 1y ago
        These are some weird sentences thrown into this thread. What you are describing is a runtime concern that has nothing to do with types. These issues are neither amplified nor alleviated by using types.
- bccdee 1y ago
  Okay? But "the features you need would have taken effort to implement, so we didn't implement them" is not a very good sales pitch when you're trying to convince me to use your tool to do my job.
  - throwawaymaths 1y ago
    ok. don't use it then. but be aware: your attitude is why things get stuck in (sometimes really awful) local minima in tech.
    - bccdee 1y ago
      Any tool that justifies the choice not to implement an important and highly-requested feature with "effort is a finite resource" alone is not viable for serious development work. It's not prioritizing, it's a refusal to prioritize.
      - throwawaymaths 1y ago
        you probably shouldn't bulldoze into a situation with assertions like you've made with such a limited grasp of the history at play.
    - deleted 1y ago
      [deleted]
OkayPhysicist 1y ago
It's likely Armstrong conflated the two there because a significant part of the fault tolerance of Erlang comes from the loose coupling via message passing between components, which in no small part is tied to the dynamic typing. It's a Postel's law thing, being generous in what you accept and strict about you send. Elixir's seamless pattern matching paradigm, IMO, largely negates the need for strict typing. If you write your function signatures to only accept data of the type / shape you need (which you are incentivized to do because it lets you unpack your data for easy processing), then you can write code just for the pretty path, where things are as expected, and do some generic coverage of the invalid state, where things aren't, rather than the norm in software development of "I covered all the individual failure states I could think of". This generic failure mode handling, too, greatly benefits from dynamic typing, since in my failure state, I by definition don't know exactly what the structure of my inputs are.
- tossandthrow 1y ago
  Yep, I have written and maintained several large scale applications In elixir and live the computation model. However,elixir depreately needs proper types. IMHO the needs for types are in no means negated by pattern matching, and I also see hints at why you would say so. > If you write your function signatures... The point of types is worry less refactoring. If you work at a place where you can define the arhicture for the entire lifecycle of the application without ever needing to Refactor, then sign me up! I want to work there.

throwawaymaths 1y ago

no, but effort is a finite resource so it justifies why they didn't bother.

tossandthrow 1y ago
Well, the people behind elixir seems to have accepted that typing is necessary. I see this story on an on: some hacker makes a language, they hate types because they want to express themselves. The languages gets traction. Now enterprise application and applications with several devs use it and typing gets essential - types will then gradually be added.
- throwawaymaths 1y ago
  sure, a few years behind typescript/mypy isnt really so bad for a language without a microsoft or a google behind it, is all im saying.
  - tossandthrow 1y ago
    > isnt really so bad for a language without a microsoft or a google behind it, is all im saying What? Elm was literally the result of a single grad students side project - elm incorporates both a sound type system and FRP. This has nothing to do with time. It was a decision not to support it.
    - throwawaymaths 1y ago
      sure part of the decision is that you can't really soundly type (in a developer sanity preserving way) across a cluster that runs multiple versions of software (which is a real use case that the authors absolutely needed to support as part of the core business). but they let dialyzer in to the core so it's not like the team was actively hostile to typing.
      - tossandthrow 1y ago
        These are some weird sentences thrown into this thread. What you are describing is a runtime concern that has nothing to do with types. These issues are neither amplified nor alleviated by using types.
bccdee 1y ago
Okay? But "the features you need would have taken effort to implement, so we didn't implement them" is not a very good sales pitch when you're trying to convince me to use your tool to do my job.
- throwawaymaths 1y ago
  ok. don't use it then. but be aware: your attitude is why things get stuck in (sometimes really awful) local minima in tech.
  - bccdee 1y ago
    Any tool that justifies the choice not to implement an important and highly-requested feature with "effort is a finite resource" alone is not viable for serious development work. It's not prioritizing, it's a refusal to prioritize.
    - throwawaymaths 1y ago
      you probably shouldn't bulldoze into a situation with assertions like you've made with such a limited grasp of the history at play.
  - deleted 1y ago
    [deleted]

OkayPhysicist 1y ago

It's likely Armstrong conflated the two there because a significant part of the fault tolerance of Erlang comes from the loose coupling via message passing between components, which in no small part is tied to the dynamic typing. It's a Postel's law thing, being generous in what you accept and strict about you send. Elixir's seamless pattern matching paradigm, IMO, largely negates the need for strict typing. If you write your function signatures to only accept data of the type / shape you need (which you are incentivized to do because it lets you unpack your data for easy processing), then you can write code just for the pretty path, where things are as expected, and do some generic coverage of the invalid state, where things aren't, rather than the norm in software development of "I covered all the individual failure states I could think of". This generic failure mode handling, too, greatly benefits from dynamic typing, since in my failure state, I by definition don't know exactly what the structure of my inputs are.

tossandthrow 1y ago
Yep, I have written and maintained several large scale applications In elixir and live the computation model. However,elixir depreately needs proper types. IMHO the needs for types are in no means negated by pattern matching, and I also see hints at why you would say so. > If you write your function signatures... The point of types is worry less refactoring. If you work at a place where you can define the arhicture for the entire lifecycle of the application without ever needing to Refactor, then sign me up! I want to work there.