Hacker News Reader

Comment by cultofmetatron | Hacker News Reader

This came at an awkward time. I just bought Richard Feldman's book "Elm in Action" a few days ago and was working through the first 2 chapters. This has made me reconsider my intention use Elm in my startup.

Having features randomly fail on me and having to rewrite an entire library in elm vs calling out to js means less time creating features that matter to my customers! I was drawn to elm as a way of spending less time debugging my own code in production. Part of that overall strategy means pulling in tested, working code whether it's also elm or js.

Some of what I see here could easily relegate elm to being a toy language; a damn shame considering how good it is as far as strongly typed functional languages to js go.

View on HN

> This has made me reconsider my intention use Elm in my startup.

Choose Boring Technology http://boringtechnology.club/

Seriously, don't use up your startup's innovation tokens on some guy's hobby programming language.

I used elixir for the backend and its paid off in dividends. That said, I had a year of experience working with it so it was boring technology for me at that point.

I use Elm on two large websites in production with users.

Elm helps me come back to these projects after months and, in two cases, a whole year, and get immediate work done without recredentializing in the whole codebase (which I have to do with my React projects to a greater extent).

You definitely can't be a fragile developer to use Elm, and I think the small community size makes people feel like others are obligated to listen to their opinions. Meanwhile they don't expect this from an ecosystem like React because they know nobody is going to listen to them, the ecosystem is just too big with too many people with hobby horses.

I've patched the compiler one two occasions for the 0.19 release. One was to allow me my Debug.crash calls. Elm is updated so slowly that it's trivial to maintain your own patch. Though I ultimately factored out my two patches.

While TFA makes some good points, just like I can enumerate the downsides of all technology that I use, a large bulk of it is just emotional catharsis. And I think this kind of exodus is a good thing. A lot of the people who supposedly leave stick around like a turd circling the drain just to give their aggressive two cents any time something negative can be said about Elm. I've always felt that to be most tiring of all. Kind of like the people who show up in every Typescript-related thread to say how static typing is for lazy developers and what not.

> One was to allow me my Debug.crash calls.

This innocent line has a lot behind it, and probably a lot of PTSD for Elm developers.

The Elm compiler has a --debug flag that would compile with a useful debugging window. It was fundamentally broken for how long? A year?

There were many, many posts about it in that time, several community forks etc. There was little comment on this from Evan or the inner circle.

The debug flag being broken, and seemingly ignored, is a horribly beautiful example of the blog post. Imagine having effectively the only debug tool broken for your main programming language

I think there may be a difference between less common and novelty, otherwise we'd all be using Java.

Elixir (Erlang) has been around for a while and I would venture that the could be considered a little boring.

It's like functional programming. It's been around for a long time and it's safe to use, but some people would call it exotic and be afraid. It's less common, but not exactly novel.

You can call out to JS using ports and custom elements and accomplish nearly everything you could possibly need. This blog post is focusing on a largely undocumented, always discouraged "feature" (used loosely, as even from its inception it was verboten, couldn't be distributed via the official package manager, etc.) which allowed users to hack library support directly into the Elm language while risking (and losing!) many of the guarantees Elm provides. Whether it's a good fit for your startup is another question, but I just wanted to assuage that concern.

This is untrue--and I'm not entirely sure you followed the article. You can't do synchronous tasks like Intl's format for strings from floats as many locales use "," over ".". It is a pure function `Float -> String`. This should not have to go through the entire update cycle to handle receiving these kinds of value. Using ports adds async to this equation which means you need to write the ports, and handle and store all temporary values which tightly couples and makes a mess everything.

It is now 'Locale -> Float -> String' or do I miss something?

Conceptually it's `Float -> String` once the Intl object is instantiated, but you can't use it in Elm anyhow. You'd have to reimplement and ship the entire in-browser Intl spec.

Dark is another startup that wrote an Elm to OCaml translator[0] after a previous language update broke their code[1].

[0] https://medium.com/darklang/philip2-an-elm-to-reasonml-compi...

[1] https://lobste.rs/s/1jftsw/philip2_elm_ocaml_compiler#c_hahl...

Don't use Elm at your startup. It's been dead for a long time. Pick something that has a huge community behind it, like React.

Just sharing my experience with Elm. Using it in production for over two years, 150K LOC elm codebase. Yes elm does have some problems, but I’ll choose elm over react/vue etc. for new project, simply because of the awesome development experience.

Reply on news.ycombinator.com