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

41–50 of 137 posts

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

#41

Post by prophesi »

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…

Sounds like Elm is run by a benevolent dictator, as is common with open source, and ended up making a difficult design choice that a lot of people didn't like.

As a newcomer to the language, I've had a pleasant experience with the community (r/elm and the Slack channel). But I can imagine drama could quickly arise if you were to debate design choices with the team behind the language.

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

#42

Post by antew »

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 runtime exceptions, refactoring is a breeze, and it really shines on larger code bases. Web-components are discounted pretty quickly in that post, but they really fill an important gap where ports are awkward.

In the years I've been using it I haven't run across a problem that I couldn't solve in a nice way. That is not to say my experience is universal, but the negative posts tend to garner a lot more attention than positive posts, and I'd feel bad if someone were to skip over what is an awesome project due to them!

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

#43

Post by dwohnitmok »

jfmengels1 wrote: post #36
baobabKoodaa wrote: post #32

I recently worked with a large Elm codebase. The original authors had moved on long ago, and nobody in the current team understood the code or Elm. There were weird state bugs all over the place. Like, you would click on a thing, it would dispatch an API request and immediately render content with stale data, then re-render once the API response came back. If the API request errored, it would hide the error and displ…

The issues you mention sound like bad usages of Msg. I recommend asking questions on the Elm Slack to try and figure out what the problems are!

Or if you have more structured questions the Elm Discourse. The Elm Slack is very ephemeral and makes it hard to contribute to a single growing source of knowledge.

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

#44

Post by savanaly »

Elm has been my language/framework of choice for writing all my side projects for several years and I am very happy. I also wrote a chrome extension productivity tool for my teammates at work in Elm.

I'm not 100% convinced of the benefits of Elm from the perspective of using it in the context of work-- the downsides like being hard to hire people to work in it and lack of external libraries for common tasks seem pretty major compared to the upsides, in the context of work. But I would not consider using anything else for my personal projects simply because it's an order of magnitude more fun to program in Elm. I've tried many JS frontend frameworks and none can compare so that's what I use.

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

#45

Post by dsiegel2275 »

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…

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 near my office). All of these interactions have been the entirely opposite of "unfriendly".

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

#46

Post by lyu07282 »

matsemann wrote: post #21
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 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.

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

#47

Post by G4BB3R »

People don't believe how typesafe Elm is until they start to use it, I never had a runtime exception. I worked a few years with TS+Vue/React, and now with Elm, and I will never go back. It is sad that a single FUD is shared much more than dozens of success stories.

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

#48

Post by jfmengels1 »

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.

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/JS have the esoteric/cool features. Elm is a very simple language, complete enough to be able to write most programs, but small enough to give you a lot of guarantees about how the code will behave.

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

#49

Post by razze »

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.

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.

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

#50

Post by hitekker »

rtfeldman wrote: post #29
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…

For what it's worth, Elm is extremely battle tested. We have over 400K lines of Elm in production, and have been using it since 2015. We've been super happy with it, and have no interest in going back to JS or TS. (To be totally honest, at this point I can't imagine even a hypothetical JS/TS framework that could bring enough benefits for us as a business to justify giving up Elm's compiler and package ecosystem. I'd…

Is Evan still working for NoRedInk? It looks like he vanished sometime around May last year.
Post reply on HN