4 ms·

Has anyone who previously preferred static typing converted (at least for certain projects) to using Elixir? I won't even put plain Node into production anymore

by spraak 7y ago

Has anyone who previously preferred static typing converted (at least for certain projects) to using Elixir? I won't even put plain Node into production anymore, TypeScript at the minimum, but otherwise OCaml or Go.

_asummers 7y ago
Came from Java. Was an adherent to static typing everything. Dialyzer via Dialyxir is imperfect but helps you bridge the gap, especially with the error message improvements available via my Erlex library. You can turn on an optional Credo rule to require @specs for every public function, and adapt the rule trivially to require on private functions. Dialyxir is notably imperfect, but it catches a surprising amount of bugs, especially with some of the optional flags.
- pavel_lishin 7y ago
  > Dialyzer via Dialyxir is imperfect Imperfect is putting it lightly. I loathe it. Aside from useless errors ("here's what the success typing looks like! Ignore the any()s, and fix it! But I won't tell you what's _wrong_!"), it doesn't run against tests (which bit my ass in production last month due to some return values being ignored, and only actually matched in tests.) > especially with the error message improvements available via my Erlex library My interest is piqued. Does it help unfuck Dialyzer error messages?
  - verttii 7y ago
    I agree, Dialyzer is just... horrible. It' hard to find anything good to say about it, unfortunately. Not that it's a trivial problem to solve, I get that.
    - PopeDotNinja 7y ago
      As someone who quite likes dialyzer, it is most certainly not optimized for user experience :P
  - _asummers 7y ago
    There is a `mix dialyzer.explain no_return` and such, which gives you at least an intuition about what the errors are looking for. Re: my library, the Erlang error messages are just wholly inappropriate so it lexes, parses and pretty prints them to give a much better user experience, due to an upstream decision to not offer the errors in AST form.
verttii 7y ago
I actually started off with Elixir but now working my way up with statically typed langs, most notably Haskell. I've found Haskell's type system allows me to express complex business logic far better than anything else I've ever gotten my hands on. It's clearly superior to Elixir in that regard in my opinion, although it does come at a price (steep learning curve). That said, in a lot of other ways Haskell is not as ideal for web development, particularly if you need clustered stateful stuff. Typescript and friends I've never really managed to develop any keen interest on, even though Typescript itself is an upgrade over JS.
- thelazydogsback 7y ago
  Sounds like F# on dotnetcore or Reason may suite you
  - verttii 7y ago
    What makes you say that? I mean what would they do better than I could do with Elixir or Haskell? I use Elixir when typical APIs or stateful soft real-time stuff is needed and Haskell whenever I have some complex data structures and logic to work on. I'm unfamiliar with F# and .NET stuff. C# I don't like one bit, if that's anywhere near that avenue. I've tried Reason but didn't quite click with it. Ended up preferring Elm for the frontend side, although Purescript could be even a better fit for me there.
    - thelazydogsback 7y ago
      Not sure why you don't like C#, as to me it's the most sane and powerful of the Java-esque languages. I'm familiar and have used all the usual suspects, and IMHO I like the .net stack. I said F# because you said you liked both Haskell (ML-style languages) and ELM. (F# however of course eager-eval like OCaml/Reason and doesn't quite have higher-order types.) And you said, "Haskell is not as ideal for web development" - and you can't really beat asp.net core on the back-end side of things. With F# you get back-end code and front-end code - the SAFE stack, ELMish, transpilation of F# to front-end JS using Fable or Xamarin WebSharper (which creates transparent proxies to exec code client-side purely from a meta-data annotation on your fn), Electron on the client, mobile (droid, iOS...) using web-tech, bindings to ReactNative, or the new Fabulous, etc.
smashedtoatoms 7y ago
I generally prefer static types. Elixir is the exception. Immutable variables and structs, coupled with OTP, make it arguably as safe for me as Typescript (whose types can lie if you get unexpected data from an api that doesn't match your type definition, for example). Refactors kind of blow though. Refactors are where I actually miss types, otherwise, I don't really notice.
Existenceblinks 7y ago
I'm all in static typing, but writing Elixir has ways less anxiety than any dynamic typed languages I've written. These are features that help eliminating uncertainties: 1. Function head pattern matching This also includes anonymous functions used in Enumerable functions like map, reduce. Which is my most favorite way of using pattern matching 2. Guard clause It's part of function definition so it's visible in very nice ways; not mess with the body. 3. Process supervision strategies Let it crash! The elegant way of dealing with exceptions and unexpected errors. It's a fair trade with static typing.

by spraak 7y ago

_asummers 7y ago

Came from Java. Was an adherent to static typing everything. Dialyzer via Dialyxir is imperfect but helps you bridge the gap, especially with the error message improvements available via my Erlex library. You can turn on an optional Credo rule to require @specs for every public function, and adapt the rule trivially to require on private functions. Dialyxir is notably imperfect, but it catches a surprising amount of bugs, especially with some of the optional flags.

pavel_lishin 7y ago
> Dialyzer via Dialyxir is imperfect Imperfect is putting it lightly. I loathe it. Aside from useless errors ("here's what the success typing looks like! Ignore the any()s, and fix it! But I won't tell you what's _wrong_!"), it doesn't run against tests (which bit my ass in production last month due to some return values being ignored, and only actually matched in tests.) > especially with the error message improvements available via my Erlex library My interest is piqued. Does it help unfuck Dialyzer error messages?
- verttii 7y ago
  I agree, Dialyzer is just... horrible. It' hard to find anything good to say about it, unfortunately. Not that it's a trivial problem to solve, I get that.
  - PopeDotNinja 7y ago
    As someone who quite likes dialyzer, it is most certainly not optimized for user experience :P
- _asummers 7y ago
  There is a `mix dialyzer.explain no_return` and such, which gives you at least an intuition about what the errors are looking for. Re: my library, the Erlang error messages are just wholly inappropriate so it lexes, parses and pretty prints them to give a much better user experience, due to an upstream decision to not offer the errors in AST form.

verttii 7y ago

I actually started off with Elixir but now working my way up with statically typed langs, most notably Haskell. I've found Haskell's type system allows me to express complex business logic far better than anything else I've ever gotten my hands on. It's clearly superior to Elixir in that regard in my opinion, although it does come at a price (steep learning curve). That said, in a lot of other ways Haskell is not as ideal for web development, particularly if you need clustered stateful stuff. Typescript and friends I've never really managed to develop any keen interest on, even though Typescript itself is an upgrade over JS.

thelazydogsback 7y ago
Sounds like F# on dotnetcore or Reason may suite you
- verttii 7y ago
  What makes you say that? I mean what would they do better than I could do with Elixir or Haskell? I use Elixir when typical APIs or stateful soft real-time stuff is needed and Haskell whenever I have some complex data structures and logic to work on. I'm unfamiliar with F# and .NET stuff. C# I don't like one bit, if that's anywhere near that avenue. I've tried Reason but didn't quite click with it. Ended up preferring Elm for the frontend side, although Purescript could be even a better fit for me there.
  - thelazydogsback 7y ago
    Not sure why you don't like C#, as to me it's the most sane and powerful of the Java-esque languages. I'm familiar and have used all the usual suspects, and IMHO I like the .net stack. I said F# because you said you liked both Haskell (ML-style languages) and ELM. (F# however of course eager-eval like OCaml/Reason and doesn't quite have higher-order types.) And you said, "Haskell is not as ideal for web development" - and you can't really beat asp.net core on the back-end side of things. With F# you get back-end code and front-end code - the SAFE stack, ELMish, transpilation of F# to front-end JS using Fable or Xamarin WebSharper (which creates transparent proxies to exec code client-side purely from a meta-data annotation on your fn), Electron on the client, mobile (droid, iOS...) using web-tech, bindings to ReactNative, or the new Fabulous, etc.

smashedtoatoms 7y ago

I generally prefer static types. Elixir is the exception. Immutable variables and structs, coupled with OTP, make it arguably as safe for me as Typescript (whose types can lie if you get unexpected data from an api that doesn't match your type definition, for example). Refactors kind of blow though. Refactors are where I actually miss types, otherwise, I don't really notice.

Existenceblinks 7y ago

I'm all in static typing, but writing Elixir has ways less anxiety than any dynamic typed languages I've written. These are features that help eliminating uncertainties: 1. Function head pattern matching This also includes anonymous functions used in Enumerable functions like map, reduce. Which is my most favorite way of using pattern matching 2. Guard clause It's part of function definition so it's visible in very nice ways; not mess with the body. 3. Process supervision strategies Let it crash! The elegant way of dealing with exceptions and unexpected errors. It's a fair trade with static typing.