One thing I noticed when I was in college was that the basics of FP is not hard, in fact it seems …

> So we need an FP language doing what GoLang did to C++. What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one. This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.

True story: when I started programming at age 11, in the book I saw a pair of assignments like: x = x + y y = y + 1 (or whatever). I was thinking, what, that has no solutions! It's just due to notations; abusing the sacrosanct equal sign for something different. People otherwise have no problem with the idea of a datum being updated in place; it's part of everyday experience.

You got me thinking and I think part of what it comes down to for typed FP languages is that you can either generally 1) Go for a simple design, but having poor interop with existing ecosystems because the language lacks equivalent features. I see Elm in this camp, and it's hard to live in because the FP community has fewer people than other communities to build up another ecosystem 2) Go for a more fully featured design, integrating with some ecosystem (like F#, Scala), but you end up with multiple overlapping concepts and inconsistency in the native language's ecosystem It seems like dynamic FP languages are the only ones to get away with a simple core and wide ecosystem by avoiding the need for features that are important for writing modular code in typed MLs. OCaml is probably closest to the sweet spot as a language+ecosystem, but the language tools are a bit weak coming from other p…