Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we chose Elm for Humio’s web UI

humio.com

Post reply on HN
Print view View original

61–70 of 137 posts

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

#61

Post by cardanome »

GiorgioG wrote: post #22
preommr wrote: post #18

Ok, exaggerations about elm's safety aside, there's the huge issue of it's readiness for production. It's not just a fledgling project, it's a project that's being carried by one person for a very broad scope, and it's been going for a very long time now. Contrast that with something like vue, where Evan You has a fair amount of corporate sponsorship, has a much smaller scope (i.e. not an entire new language), big fo…

The bus-factor of one is too high a risk for me unless I'm creating a throw-away project.

Elm is not something that needs regular security updates or something. It is super stable and has a relatively slow release cycle.

Even if the creator died or lost interest you would be still fine to use it. The community could still provide critical patches if their was a need. Feature development might slow down but if it is already offering everything you need that is not really an issue, no?

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

#62

Post by matsemann »

lyu07282 wrote: post #46
matsemann wrote: post #21

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…

a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.

> a true believer I can tell

Just fuck off with that kind of comment. I provided a well reasoned post, dismissing my views like that just because they don't align with yours is dishonest on your part and no way to have a discussion.

To answer your claims: No, I couldn't easily say the same about TS/react. In elm the language forces the architecture and safety. In react it can be whatever you want with leaks and unsafe modifications all over the place.

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

#63

Post by napsterbr »

deergomoo wrote: post #16

Apologies if this is too off-topic, but I'm currently trying to decide between Elm and ClojureScript to get started with FP. Can anyone weigh in with recommendations? The points this article makes like strong typing pull me towards Elm, but people talk about understanding Lisps as a nirvana-like state of enlightenment, which pulls me towards Cljs

I worked with Elm for 2 (or maybe 3?) years, and with Clojurescript for another 2. I recently had to decide on which of the two I would use on my next project, and it was definitely not an easy decision. Ultimately, I went with Clojurescript.

Main Clojurescript pro was re-frame[0]. Re-frame makes state handling easy and, especially importantly for performance-sensitive projects, it entirely removes the (rather common) problem of re-renders with the way its subscriptions are handled. This, plus the ability to have your entire stack in a single (amazing) language, were the tipping points to me.

While you can't achieve the same level of compile-time safety in Clojurescript, you can apply "state checks" (with Spec or any custom validation mechanism) any time your state changes. And with re-frame, it is extremely clear when your state changes, therefore you can block any invalid state from being saved and catching it as soon as it happens. Again, not the same kind of safety you have with Elm, but to me it's a good-enough trade-off.

And that's exactly what I do with my code: every time my state changes, I run a validation check on the keys that are about to change. If their value is deemed invalid, an error popup (identical to old Windows XP error popups, because why not) will appear, stating what the invalid state is and what it should be like instead, as well as which event led to this state in the first place. This check is so fast I don't even need to disable it in the production build (but instead of a popup we get a notification that an invalid state error happened).

In fact, there's this (non-mainstream) argument that runtime checks bring even more power over typing: https://www.youtube.com/watch?v=nqY4nUMfus8

TL;DR: Not an easy decision, but the truth is whichever one you pick, it will be a great choice.

[0] - https://github.com/day8/re-frame/

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

#64

Post by al2o3cr »

Side note: the linked page displays a blank screen with a cookie banner on on my old Safari along with console messages about "Can't find variable: IntersectionObserver". Yay web standards!

My Elm experience was that, even with the author of an Elm book on the team, it only took one "generic" component to hit the limitations of the type system.

More specifically, this was for an electric utility dashboard / control application that needed realtime charts for many kinds of values (watts, amps, etc). We were good little Strong Typers and made each kind of unit a tagged type (so "KilowattHours v" etc) and made conversion utilities (kWh -> Wh and so on). Fantastic, no way to accidentally add together kWh and MW to produce nonsense.

But there's no "value with any unit" type the way we set it up - after all, the whole point was that you _can't_ substitute the wrong kind of value - so it becomes impossible to EXPRESS the type of a generic function from "List of values with units" to "graph".

The compiler is a mixed bag: on the one hand, the marketing is true - you can just keep fixing error messages until they stop and your code will likely be correct. On the other hand, "until they stop" is not a great complexity bound; displaying timestamps in "the current user's timezone" in our application required an 800+ line change.

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

#65

Post by heterodoxxed »

jfmengels1 wrote: post #48
lyu07282 wrote: post #46

Earlier quoted context omitted.

a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.

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.

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

#66

Post by jlengrand »

dd82 wrote: post #27

Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge. The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And…

I have read those, and have built a few side-projects in Elm. There is a large difference between 'the community' as in the folks deciding of the future of the language, and 'the community' aka the huge majority of the users of the language. Elm has one of the most welcoming communities I've ever seen. They are ready to explain the same concepts again and again in their slack and many of them (quite a few being here in the comments actually) are not only helpful in Elm, but wholesome humans as well.

Elm is IMHO extremely friendly, especially to newcomers. The leadership style however is up for debate but that's another story.

I wouldn't bet my company on Elm personally, but I can't recommend it enough for side projects and folks interested in learning more FP or simply for fun.

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

#67

Post by aeturnum »

I've also got a little side project in Elm and, like a lot of folks here, the experience has been very mixed. On one hand, when Elm is happy, it does just work. It's fast and relatively svelte and generally great. Its errors are clear and easy to understand, though not always easy to solve.

The downsides of Elm are that the language really does have different expectations than less purely functional lambda-calculus inspired languages. I found dealing with my projects' Msg types, in particular, to be a pain. Once you understand the Elm way of thinking about things it does make sense.

My sense of the community is that they are extremely helpful about showing you the "elm-ish" solution to your problem. They can be pretty obtuse about *why* that is the way to do it. In general, I thought the transition from imperative OO langauges like JS to the lisp-ish Elm was a lot harder than it needed to be. I would ask why my approach wasn't working and get a reply telling me to do it a different way - which didn't really help me understand why my approach didn't work. I can understand why it would be exhausting to try to meet people where they are, but I also get why the "do it this way" approach is off-putting.

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

#68

Post by lyu07282 »

matsemann wrote: post #62
lyu07282 wrote: post #46

Earlier quoted context omitted.

a true believer I can tell. But you could easily say the same thing about a well architected typescript/react frontend app, its just that it has several orders of magnitude more experienced developers and billions in corporate sponsorship behind it. Which is significantly more important than any cool feature the hip esoteric language of the week may have.

> a true believer I can tell Just fuck off with that kind of comment. I provided a well reasoned post, dismissing my views like that just because they don't align with yours is dishonest on your part and no way to have a discussion. To answer your claims: No, I couldn't easily say the same about TS/react. In elm the language forces the architecture and safety. In react it can be whatever you want with leaks and unsaf…

That was mostly in response to your statement "it can be hard to believe when not experienced first hand just how hard it is to introduce bugs in elm"

Is just about the most ridiculous thing I ever heard (and certainly what a "true believer" would say even if you obviously and predictably disagree)

That a true believer will react angry to criticism is entirely self evident.

There are thousands of times more developers and companies using typescript over Elm, there is inherent value in this simple fact. No matter how much steam escapes your ears, its true.

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

#69

Post by dhucerbin »

antew wrote: post #42
dd82 wrote: post #27

Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge. The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And…

That "Why I'm Leaving Elm" post comes up on most Elm discussions, and I would implore anyone to give it a try for themselves before deciding against it. I've been working in Elm professionally for a few years now and I think Luke's experience in that blog post is certainly atypical. For writing web applications Elm is an excellent language to work in, the compiler is friendly and fast, there are basically zero runtim…

> I think Luke's experience in that blog post is certainly atypical.

> the negative posts tend to garner a lot more attention than positive posts

On the other hand, my team was very unsatisfied with Elm and when we bring those issues to community we were quickly asked to leave. Of course it is fair but please note that negative opinions are discouraged and thus not common. We just disengaged from community and started elsewhere.

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

#70

Post by leshow »

antew wrote: post #42
dd82 wrote: post #27

Elm as a language is really nice, and I do like the goals of the project. I tried it out a bit, its a mind-bending paradigm for someone coming from OOP/prototype (Python, Java, JS) and I enjoyed the challenge. The community, on the other hand, is what turned me off. It does seem very unfriendly to newcomers. In addition, https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ amongst others, is an entire turnoff. And…

That "Why I'm Leaving Elm" post comes up on most Elm discussions, and I would implore anyone to give it a try for themselves before deciding against it. I've been working in Elm professionally for a few years now and I think Luke's experience in that blog post is certainly atypical. For writing web applications Elm is an excellent language to work in, the compiler is friendly and fast, there are basically zero runtim…

It's not just luke, here's a couple more, two of these I remember in particular the others are just from a google search

https://reasonablypolymorphic.com/blog/elm-is-wrong/

https://dev.to/kspeakman/elm-019-broke-us--khn

https://blog.bitsrc.io/elm-and-why-its-not-quite-ready-yet-2...

https://medium.com/@cscalfani/the-biggest-problem-with-elm-4...

I've come to view Elm as someones personal compiler project. If you are good with the decisions made then you're going to have a fine time, otherwise you probably won't

Post reply on HN