5 ms·

I’ve been writing Elm professionally for the past 2.5 years on a large project. The language is a pure joy to use, unparalleled refactoring experience. Yes it’s

I’ve been writing Elm professionally for the past 2.5 years on a large project. The language is a pure joy to use, unparalleled refactoring experience. Yes it’s a small community, but there’s many jobs posted on Elm slack.

onethought 5y ago
It’s quite parallel to typescript (strict) refactoring, isn’t it?
- weavie 5y ago
  I suspect not. With Typescript even with strict typing, mutating state is still possible (I believe, correct me if I'm wrong..). This adds an extra layer of complexity to the refactoring process. With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much easier refactoring.
  - piaste 5y ago
    > This does mean you have to jump through a number of hoops to use FFI. TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code. I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).
- deleted 5y ago
  [deleted]
- razze 5y ago
  Honestly, it's nothing alike. Refactoring in Elm is different, as the compiler will tell you if you did the correct thing when refactoring. The typescript compiler can only do a fraction of that, even if you type your stuff correctly. Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.

onethought 5y ago

It’s quite parallel to typescript (strict) refactoring, isn’t it?

weavie 5y ago
I suspect not. With Typescript even with strict typing, mutating state is still possible (I believe, correct me if I'm wrong..). This adds an extra layer of complexity to the refactoring process. With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much easier refactoring.
- piaste 5y ago
  > This does mean you have to jump through a number of hoops to use FFI. TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code. I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).
deleted 5y ago
[deleted]
razze 5y ago
Honestly, it's nothing alike. Refactoring in Elm is different, as the compiler will tell you if you did the correct thing when refactoring. The typescript compiler can only do a fraction of that, even if you type your stuff correctly. Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.