Using both Elm and F#. Here are a few things that irk me.
Hazardous generics
Elm : Result SomeErrorType SomeType
F# : Result<SomeType, SomeErrorType> - The sharp angles cut me
Elm union types do not allow an optional leading |, which makes the first one a pain to copy/paste, diff, etc. (Maybe implemented soon.)
-- ElmtypeSomeUnion=FooCase-- merge conflict waiting to happen|BarCase
// F#typeSomeUnion=|FooCase|BarCase
F# let syntax is nicer to use. Elm let statements require an in clause whereas it is optional/implicit in F#. Additionally, elm-format always expands let statements to multi-line. The visually-enormous resulting code leads you to want to avoid let in Elm.
// F# - easier to read IMOletasdf=oneLinerxletfdsa=anotherOneLineryfasdffdsa
Elm generates curried constructors for all record and union types. Curried constructors are great because they support partial application. F# does not, and the normal record construction syntax is quite verbose. I often create my own curried constructor for partial application.
// F#typeSomeType={SomeInt:intSomeString:stringSomeFloat:double}// make my own curried constructorletmkSomeTypeabc={SomeInt=a;SomeString=b;SomeFloat=c}letx=mkSomeType1"foo"3.14letlist=List.map(mkSomeType1"foo")[3.14;2.718]
Here is what the last two lines would look like in C#.
Using both Elm and F#. Here are a few things that irk me.
Hazardous generics
Elm :
Result SomeErrorType SomeType
F# :
Result<SomeType, SomeErrorType>
- The sharp angles cut meElm union types do not allow an optional leading
|
, which makes the first one a pain to copy/paste, diff, etc. (Maybe implemented soon.)let
syntax is nicer to use. Elmlet
statements require anin
clause whereas it is optional/implicit in F#. Additionally, elm-format always expandslet
statements to multi-line. The visually-enormous resulting code leads you to want to avoidlet
in Elm.Here is what the last two lines would look like in C#.