1. 20
    1. 3

      This plain-text blog post doesn’t load without JS enabled and doesn’t load in a reader view.

      Elm is opinionated and restrictive.

      Could you expand on when you’ve wanted to do things but Elm restricts you from doing those things? It’s easy enough for me to imagine or guess, but I was hoping for specific anecdotes from a half-decade of experience.

      1. 10

        This plain-text blog post doesn’t load without JS enabled and doesn’t load in a reader view.

        Or so I’ve heard. I’ve let the team behind the blog know.

        Elm is opinionated and restrictive

        I don’t know if it’s things that I wanted to do, since with experience I have come to appreciate the trade-offs involved. But one example is the fact that data from outside Elm is not trusted.

        When you receive the result of an HTTP request or interact with JavaScript (through ports), you need to “decode” (validate) to indicate that it’s in a shape that is acceptable. You can’t do request.body.user.name willy-nilly, because request.body.user might not exist or not be a JSON record. You need to first validate it. Once it has been decoded, the code acting on that data is runtime-error free though! That is one mechanism through which Elm can pretty much guarantee that there will no runtime error.

        Another example is the handling of errors. If you try to access the response from an HTTP request, you need to validate that the request was successful, and handle the case where it failed. Even things that seem simple like accessing the first element of a list requires you to handle the case where the list is empty.

        Immutability is also another restriction. Sometimes, you wish to mutate a value somewhere deep down in your function-call stack, but the language won’t allow you to. In those cases, you need to return the updated value at every step of the function call, which can be annoying. It doesn’t feel nice when you have to do a lot of work to make this work, but I have grown to accept it because the trade-offs and guarantees that I get from all these restrictions and opinions are worth it in my opinion.

    2. 2

      How do you feel about the project being put on hold since Oct 2019?

      1. 6

        I imagine that you’re talking about Elm (and not Humio)? The project hasn’t been put on hold. I talk to Evan, the creator of Elm, from time to time (including on my Elm podcast only a couple weeks ago https://elm-radio.com/episode/open-source-funding ).

        I know some people said there has been no activity on the elm/compiler project in a while and therefore that the project has been put on hold. But that is not the only project that he works on. There are other projects that he maintains. He does work mostly in private repositories so as not to “excite” people with features that he is exploring but that may not pan out.

        That said, most activity in the Elm ecosystem now comes from the community, such as tooling (such as myself) and package authors. We as a community are in a spot where we have most of the tools available and we’re not dependent on Evan unblocking us one way or another, because the language has reached a certain level of stability and maturity.

        The project is most definitely not on hold nor dead :)

        1. 3

          Yes I was talking about Elm, and I didn’t mean to imply that it was dead or permanently on hold. However, the last release was in Oct 2019 and I know Evan said he was taking some time off to work on some experiments — a post that I can’t for the life of me locate. I just think that I’d be nervous hitching my business to a technology where the core compiler hasn’t seen a release in that amount of time and I was wondering how the folks at Humio felt about that.

          1. 5

            I think you’re thinking of https://discourse.elm-lang.org/t/where-can-we-find-the-roadmap-of-elm/6038/2?u=jfmengels (or something close). I agree that it can be scary to rely on a tool with few releases, or at least few bugfix releases. At Humio we have been “lucky” not to have been blocked by a bug. I put “lucky” in between quotes because the compiler is of a surprisingly high quality for something with so few releases.

            Most of the problematic bugs that people encounter (and for a few is a deal-breaker) are not related to the compiler though, but to some of the core libraries. They receive more frequent updates, though they are also quite sparse.

            Evan likes to batch work, meaning that he likes to focus on few topics at a time until a point where he’s content with it, and I personally feel that has produced some absolutely amazing results, therefore I accept the “trade-off”.

            But no-one on the team has complained about the infrequent releases of the compiler or of the language, and I’m pretty sure everyone here appreciates the stability of the language and not having to learn about a new version of the language.

            1. 2

              Yes that’s the post, thanks. I also just noticed it’s in the compiler repo too: https://github.com/elm/compiler/blob/master/roadmap.md Glad to hear it’s working for you and I’m interested to see what Evan’s “exploratory work” yields.

    3. 1

      What parts of the UI are running Elm? Having been a customer, it would be really nice to get an understanding of how Elm is driving the experience.

      1. 3

        All of the product (not the marketing website) is written in Elm, for instance the search and dashboard pages. The charts were rendered with Highcharts or Vega (depending on when you used it) through JS and webcomponents. I’m not sure what you wish to know about how Elm is driving the experience though :)