Live data from Hacker News

Why we chose Elm for Humio’s web UI

humio.com

121–130 of 137 posts

Re: Why we chose Elm for Humio’s web UI

#121

Earlier quoted context omitted.

Could you share some screenshots of the complex UIs you're building over at GWI? It always helps me to understand other perspectives as difficulty/complexity seems to be relative in discussions around UIs most of the time.

Sure thing! Here is an Imgur album with screenshots of some of the apps: https://imgur.com/a/GCxSrr1

Thanks a lot for sharing those! Very interesting to see. The "crosstab" page looks like it was a lot of fun to implement! :)

Re: Why we chose Elm for Humio’s web UI

#123

Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.

Concourse uses Elm for its front-end: https://github.com/concourse/concourse

The elm part: https://github.com/concourse/concourse

Re: Why we chose Elm for Humio’s web UI

#124

Earlier quoted context omitted.

What do you do when network requests fail for essential parts of the application?

I'm not a language researcher/expert but real life code is full of colaterals and side effects, specially having to deal with things like network the expectation that f(x) will always resolve to a valid answer without resorting to result being of another sort even if normalized to the expected type (eg, you are doing a simple integer calculation and define that the negative numbers will be used as error codes to deal…

You don't expect a function that hits the network to always return a valid answer though. That function would return a Result type which has Ok and Err constructors which you match against. Here's a self contained example that explains it better than I can[0].

> if we managed to program in a "multidimensional-state paradigm", where you could call a "multidimensional f(x)" where in one dimension of the state it will always be a valid reply, and the side effects would be another f(x) that would solve the side-effects in parallel, but both functions would be intrinsically bounded to each other like in the schrodinger's cat experiment.

You're _kind of_ talking about monadic binding here, which is called the `andThen` pattern in Elm. You can see it in JS when handling promises too.

[0] https://guide.elm-lang.org/effects/http.html

Re: Why we chose Elm for Humio’s web UI

#125
post #83

Earlier quoted context omitted.

Maybe you've had direct interactions with community members, but it is very unfair for you to characterize the Elm community as "unfriendly" based off of your reading of a few posts. My actual experience has been exactly the opposite: I've interacted with many members of the community (at multiple Elm conferences, in the Slack, and even twice met members of the community for in-person meetings when they were visiting…

Of course the community is friendly: all dissent is ruthlessly crushed and removed. It feels very friendly and nice until you start to dissent, then it turns on you hard. I posted an article saying I now recommended elm and was a part of the reason we chose it for our product. But I also said some things I disliked about elm. So I was banned. No warning.

Banned from where the discourse?

Re: Why we chose Elm for Humio’s web UI

#126
post #97

Earlier quoted context omitted.

> It's not like it would stop working out of the blue. Unless the benevolent dictator pushes out a new Elm version that is not backward compatible. And, if the process is the same it was a few years ago, it could happen next month and only a happy few know it. The development is done behind closed doors. It happened to a project of mine, from version 0.17 to 0.18 IIRC. The choice was between letting the code slowly r…

Same here. Still on 0.18, no upgrade path as 70% of my deps never upgraded. Awaiting rewrite in vue/react/etc

You can just vendor those dependencies, that's what I did, but I only had one that didn't update. And that one was trivial to fix.

Re: Why we chose Elm for Humio’s web UI

#127

Earlier quoted context omitted.

The safety isn't an exaggeration, though I can understand it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm. Like type safety eliminates one type of bugs, elm's stricter safety eliminates even more. When there is only one place in the whole code base that is allowed to have side effects, that removes lots of the bugs normally seen in frontend. Can't recall we ever…

> It's not like it would stop working out of the blue. Unless the benevolent dictator pushes out a new Elm version that is not backward compatible. And, if the process is the same it was a few years ago, it could happen next month and only a happy few know it. The development is done behind closed doors. It happened to a project of mine, from version 0.17 to 0.18 IIRC. The choice was between letting the code slowly r…

> Unless the benevolent dictator pushes out a new Elm version that is not backward compatible.

That wouldn't break your build/deploy out of the blue, as you don't get force updated to the latest version.

And having worked on the 0.19 transition, it was in public preview for about 3/4 of a year and regularly discussed in the elm slack. When 0.19.1 came about, there were some more pre-release versions, where evan asked people to test and give feedback in slack. Can't speak for versions before that.

Re: Why we chose Elm for Humio’s web UI

#128

Earlier quoted context omitted.

I couldn't say the same thing for even well-architected TS apps. There are important escape hatches that TS gives that make it unreliable, as summarized in this article: https://incrementalelm.com/tips/typescript-blind-spots/ Refactoring code or updating dependencies is and feels a lot safer in Elm than in TS, and doesn't require asking for every npm package author to add TS type definitions. I'd also argue that TS/J…

| There are important escape hatches that TS gives that make it unreliable This is one way to mitigate those escape hatches: https://github.com/cyrilletuzi/typescript-strictly-typed But in my experience, you had better be starting a new project. They aren't joking when they say laying it on an existing codebase is a nightmare.

Do you know if that somehow fixes https://github.com/microsoft/TypeScript/issues/8677 ? That's still the most annoying thing about typescript for me.

Re: Why we chose Elm for Humio’s web UI

#129
post #49

Earlier quoted context omitted.

I'm pretty sure if your honest all you projects end up having this bus factor (check all your dependencies). If you really care to look, most projects are run by a small group of people.

I’m pretty sure you’d be wrong. I would never build a software product or service that uses a compiler written and maintained by a single person.

Interesting, why are compilers special in your POV? Why do they need regular maintenance and why don't they allow extension via some kind interfaces, thus allowing for less maintenance?

Re: Why we chose Elm for Humio’s web UI

#130

Are there any large open-source Elm apps? I've had trouble finding anything other than toys, libraries, or dev tools.

https://builtwithelm.co/ lists some, but not sure what you consider large.

Not sure if you would categorize this as dev tool https://github.com/erkal/kite

And ellie certainly might be a dev-tool, but not a toy https://github.com/ellie-app/ellie

Post reply on HN