Union Types in Flow and Reason (opens in new tab)

I’m going to echo the Haskell recommendations. Just get started.

I was also overwhelmed by how convoluted the language seemed but eventually used it for a project, and my opinion completely changed. Haskell is a simple, beautiful language that enjoys great tooling.

Start out by learning just enough IO and monad stuff so that you can read input and pass it to your functions. This will not take long. Then you can gradually build up your knowledge of the language by creating modules that will become more and more idiomatic with time. You will discover parametrized types, laziness, and user-defined operators. At times you will struggle with how to use the type system to achieve your goal, but through practice, you will learn how it limits you, so you will know what approach to take.

Eventually you might notice that your code could be easier to read and write, and that’s where monads come in.

Somebody in this thread also recommended Clojure, which is a fine language that I would have also recommended a few months ago—it was my go-to language for spinning up servers or doing some computation. Now that I have tried Haskell though, I feel like I might not need to use Clojure again because Haskell is much more fun. So I’d hate for someone else to miss out on the fun like I did for years because they think they have to read a 600-page treatise just to get started! It’s very far from the truth.

Considering you mention not having programmed extensively in a functional language, I'd say you should pick a language with extensive documentation for beginners. I know you dismissed it, but many people have put a lot of time and thought into designing materials for learning Haskell. In particular, I think most people recommend the Haskell book[1].

That being said, all the choices you list (Elm, Haskell, F#, OCaml, PureScript) are solid languages with good communities. The core languages are similar enough that if you start learning one, the things you learn will transfer decently enough to all the others.

[1]: Haskell Programming from First Principles (http://haskellbook.com/)

You can check with Clojure and ClojureScript to target JS specifically. You can write your backend in Clojure and the front part in ClojureScript. Having the possibility to use the same language for both is great.

It's a mature functional language with interesting properties, it's practical, data oriented. Libraries quality are top notch, you'll find no big framework but libraries working together to achieve what you want.

Some ClojureScript libraries are awesome, for example if you're on React you have Reagent or Rum that are fantastic libraries to work with React.

OP post could be written like this in Clojure (if you want to be explicit with all the screens):

    (defn needs-cancel-button [screen]
        (case screen
            :screens/loading true
            :screens/code-entry true
            :screens/success false))

You'll notice that this is not typed but you can use Clojure spec to have some validation (this way being less explicit just returning false for the Success Screen, and true otherwise):

    (def screens #{:screens/loading :screens/code-entry :screens/success})	
    (defn needs-cancel-button 
        [screen]
        {:pre [(s/valid? screens screen)]}
        (case screen
            :screens/success false
            true))

Union types can be mimicked using spec, you'll find how here: https://lambdaisland.com/blog/25-09-2016-union-types

OCaml is also great, IMO you won't lose your time by learning these languages, you'll find some way to improve your current code

Whether you learn Clojure, OCaml, F#, Haskell, Elm or Haskell, you'll end up being a better developer.

All your points (1 through 4) matched with what was looking for. I chose Clojure. It's Lispy, focuses on immutable data (but not necessarily pure functions), has a version (cljs) that compiles to javascript (if you're writing web-apps, its great to write both your front-end and backend code in one langauage). I've broadly found clojure to be a "practical" functional language to work in.

(If it helps, I'm primarily a python/js developer before picking Clojure).

The core of haskell is relatively straightforward, believe it or not -- it's just that a lot of what is blogged about is bleedong edge, either language-wise or in concepts they explain.

PureScript is pretty much haskell, it simply compiles to javascript -- wouldn't say there is much skill transferability in terms of language when coming from js, but it might make sense if you develop front-end.

Don't know about the other languages.

I went through all of the languages you mention, and OCaml/ReasonML are what you're looking for (if you want a typed FP language). More than 50% of FB messenger is written in ReasonML so it's clearly a good long term investment. If you don't like the ReasonML syntax, then you can just use OCaml because they're 100% interoperable. It's also a very practical language, which unlike the others doesn't militantly enforce purity, and lets you directly write imperative code.

I wanted the answer to a similar question for myself to be f#/fable - but it turned out that getting up and running on Linux with dot.net core and cli tooling was a bit convoluted.

I did manage to bundle a ~32mb hello world with dependencies/runtime (with cross-compilation, yay!) - but I couldn't get giraffe or any other server (framework) running in a reasonable amount of time. (Side-note, I'd appreciate a pointer to a f# Web server stack that works in the above scenario - something light that's appropriate to build a json-api server in).

Many tutorials appeared to be a year out of date, with wrong details - leading to code snippets not working, things not building, dependencies not installing.

Since I know ocaml is solid, I now am a strong believer in reasonml (which fixes some of the oddities with ocaml, making it more pleasant - in a way a little more like standard ml).

Reasonml has a strong Web app side, and compiles to sane js.

The other great option is clojure/clojure script. It's been dogged a bit by jvm (startup) overhead - not sure how/if graal/truffle AOT compilation will improve that.

Are you specifically looking for an introduction to functional programming, or to more generally modern language features? The strong static typing of Haskell or OCaml is orthogonal to their functional properties, but they tend to go together because they were designed by academic types in the last 20-ish years. Assuming you're interested in all of the above:

For immediate productivity, I would recommend Scala - it's run on the JVM, and lets you fall back to a fairly Java-like subset. It's ugly in some ways, but has a more mature web programming ecosystem than a lot of other functional programming languages - a decent backend framework in Play and Scala.js for maybe writing a few critical browser-side libraries - and has decent and growing adoption.

If you're not looking for quick productivity in web development, and don't care all that much about learning a language that's immediately applicable to existing job opportunities, I'd probably recommend the more "pure" modern languages like Haskell or OCaml; they're niche, but it's a stable niche, especially in more academic circles, and will give you a cleaner mental model of all the features that are hackily being tacked on in JS and Scala.

I've heard good things about Clojure (think LISP on the JVM), but haven't personally tried it and don't know how vibrant its community is. Having access to JVM libraries, as with Scala, is a great plus for immediate productivity.

The purescript example in the post shows one of Purescript’s biggest problems, and that’s non-optimal codegen.

The series of if checks (O(n)) it generates as opposed to a switch statement can really add up in loops with bigger enums.

Of the langs listed, ReasonML/OCaml have the best codegen/ffi story, it’s relatively easy to drop them into existing JS projects.

apologies for recommending to extend your scope of interest. But I would highly recommend to add to your list of 'targets': mobile development. That's because you mentioned: longterm.

Longerm, in my views, means being able to write software for web, desktop, multiple smart-phone/table platforms, with a backend in, ideally, the same language/tooling as front end.

It seems like ReasonML is the only one that is targeting the above [1] (but I could be wrong). And that's because of its integration/support of ReactNative.

[1] https://medium.com/@peterpme/your-first-reasonml-pr-into-an-...

I'd go for F#, OCaml, Scala, or possibly Rust.

Elm, Purescript and ReasonML feel like much smaller communities that I wouldn't trust to necessarily make for a good long-term investment; Haskell is a bit too much of a jump to get productive in immediately. If you learn like I do - incrementally - then you want a strictly-evaluated, mainstream-ey language that allows you to write side effects without tracking them, just to start with.

How about Kotlin? First class support on Android. Great tooling and compiles to JS

Scala.js is a great, stable, mature tool. Scala is a sharp sword, but it fits your criteria quite well. I'm certainly enjoying Scala.js very much.

Not just that, the initial Flow example can actually be translated 1-to-1 to TypeScript (without using enums at all):

https://www.typescriptlang.org/play/index.html#src=type%20Ap...

Ah! Thanks for pointing this out, I'll be sure update the post. (I haven't used TypeScript all that extensively, so I didn't even know about `const enum`.)

I hope the author adds this correction to his article because there’s no way to comment on it directly.

Ah, that's my mistake! The generated Reason output got copy/pasted incorrectly. (It's correct if you click through to the Try Reason link.)

In fact, Reason generates the `>=` comparison, and it knows it can do this because it know that a value greater than 2 can never happen.

The post should be updated to reflect this in a second!

I believe this is because it takes an enum, not an integer. Perhaps Reason is communicating this to uglify?

Read the linked previous post[1]. Flow doesn't ensure exhaustiveness unless you ask it to, by telling it that any case that goes to "default" is invalid (impossible).

[1] https://blog.jez.io/flow-exhaustiveness/

You can also just cast screen to empty in the default case by adding a line that says (screen: empty). This is how the flow docs recommend doing it in Redux reducers.

This doesn't sound right

Sum types are not more capable of an abstraction than union types. If we consider them in isolation, they are strictly less capable. For example, its possible to model sum types using union types in TypeScript by simply adding a tag field:

  type Either<T, U> = { kind: 'left',  left: T } 
                    | { kind: 'right', right: U }

If you do this, typescript will also be able to do exhaustiveness checks provided its configured with noImplicitAny and strictNullChecks:

For example, try removing a case item in the below code (paste it on http://www.typescriptlang.org/play/ and in options turn on the above mentioned checks):

  type Stringifiable = { toString(): string };

  function stringify<T extends Stringifiable, U extends Stringifiable>(thing: Either<T, U>):string {
    switch (thing.kind) {
      case 'left': return 'Left ' + thing.left.toString()
      case 'right': return 'Right ' + thing.right.toString()
    }
  }

edit: additionally, PureScript row types are not strictly better. While row polymorphic records are a better tool to model records (they can model open or closed records and subtype relations are not needlessly complex), AFAIK PureScript still lacks advanced transformation tools such as mapped and conditional types which really make TS records shine (see https://www.typescriptlang.org/docs/handbook/release-notes/t... for example)

Motivating example (given a record type, returns a record type containing only the properties that are not functions):

  type NonFunctionPropertyNames<T> = { 
    [K in keyof T]: T[K] extends Function ? never : K 
  }[keyof T];

  type NonFunctionProperties<T> = { [P in NonFunctionPropertyNames<T>]: T[P] };

Would love to see a guide on using bucklescript with VueJS.

They seem overused and overpraised. They have their uses, but largely you don't want to mash together different things in a program if you can avoid it. Because it leads to unmaintainable switching code. Alternatives: Have n containers of simple types instead of one container with elements of union types with n alternatives. Sometimes that's not possible because you need to process them in a specific order, but even then you can just keep an additional reference table that references into the n containers. Another alternative would be to make the type an ADT (of course, not always applicable, either).