What’s so great about functional programming anyway?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • Fable: F# |> BABEL

    F# to JavaScript, TypeScript, Python, Rust and Dart Compiler

    Or https://fable.io in the F# world, which is production ready and excellent

  • eioio

    Effects-based direct-style IO for multicore OCaml

    > This is realllly unidiomatic in real world Haskell.

    Whether idiomatic or not does not matter. It proves my point:

    IO won't save you, and even very mundane effects are not part of the game…

    Idris is the "better Haskell" sure, but the effect tracking is still part of the uncanny valley (still IO monad based).

    Koka is a toy, and Frank mostly "only a paper" (even there is some code out there).

    The "Frank concept" is to some degree implemented in the Unison language, though:


    Having a notion of co-effects (or however you please to call them) is imho actually much more important than talking about effects (as effects are in fact neither values nor types—something that all the IO kludges get wrong).

    I think the first practicable approach in the mainstream about this topic will be what gets researched and developed for Scala. The main take away is that you need to look at things form the co-effects side first and foremost!

    In case anybody is interested in what happens in Scala land in this regard:



    But also the development in OCaml seems interesting:


    Look mom, "effects", but without the monad headache!

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • hylo

    The Hylo programming language

    I think functional programming is great for scaling systems but too restrictive...

    So the model of the future, in my opinion, should look more like https://www.val-lang.dev/


    This is less restrictive and also very scalable IMHO. Value semantics, basically.

  • hoogle

    Haskell API search engine

    > In something like Haskell I need to know upfront what I may do with some "object". The IDE can't help me discover the methods I need. All it can do is to show me all available functions in scope.

    Sorry, but this just isn't true. Hoogle <https://hoogle.haskell.org/> searches function by type, fuzzily: ask for functions whose first parameter is the type of the object-like thing, and you'll get just what you're looking for. And it's perfectly possible to run hoogle locally and integrate it with your editor.

    Now, the tooling for a language like Java have had several centuries more of aggregate development work done on them compared to Haskell's tools, and if that polish is a difference-maker for you, that's fine! But it's not a fundamental limitation, and claiming it is is just fud.

  • Persistent Collection

    A Persistent Java Collections Library

    > If you are using containers, always, always, always use immutable containers from Google Guava unless you have an exceptionally good reason.

    I actually prefer pcollections: https://github.com/hrldcpr/pcollections

    AtomicReference + immutable data types is a really nice way to program in Java, and is basically the way most Clojure programs are written.

  • haskell-mode

    Emacs mode for Haskell

    If I made it sound like there's something like IntelliSense today, apologies! We've got <https://github.com/haskell/haskell-mode/blob/master/haskell-...>, but it's type-a-command-and-do-a-search: it's not linked in with completion directly in the setups I've seen.

    (In practice, I'm usually starting from a slightly different place: I know I want a Frob and I've got a This and a That, so I do :hoogle This -> That -> Frob and get some options. The thought-process is working backwards from the goal more than forwards from one key object in focus. A different way of working, but I'm not convinced it's less effective.)

    My point though was that it's an engineering issue, not a fundamental language limitation. ie not a reason all future languages should shun haskell features. The building blocks to do better at completion than haskell curently does are there.

  • functional-programming-jargon

    Jargon from the functional programming world in simple terms!

    Functional Programming Jargon is great at explaining these concepts. Monad: https://github.com/hemanth/functional-programming-jargon#mon...

    Purists will say it's not entirely correct, but we don't care about purism :)

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • ZIO

    ZIO — A type-safe, composable library for async and concurrent programming in Scala

    > It's a weakness of functional programming, not the language.

    I would strongly object this.

    Have you seen ZIO?


NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts