My Elm Experience | Hacker News Reader

My Elm Experience

underjord.io

114 pointslawik97 comments

I programmed with Elm for 3 years and love it - best programming experience I’ve ever had. I had to stop because I started working on some educational game projects that had incredibly short timelines and frequent, large change requests and depended on some WebGL 3D and game libraries. Nothing beats the super productivity of JS for hacking something together fast, and despite JS being far less reliable, the productivity and flexibility made up for that. Yes, there were run-time errors, but they were really a minor problem. JS, whatever it’s many faults may be, is fast and fun.

What slowed me down with Elm was JSON parsing, which needs to be done manually and can take hours or days whereas the same thing in JS takes about 2 seconds to type an import statement. And the other thing was using BabaylonJS and Phaser - you can certainly use them with Elm but you’ll need to commit to months of extra work to build port-based interfaces to them. And, games live in the world of side-effects, which is a chore in Elm. I needed to get finished games out in days - which I was able to hacking my way through with JS.

Having used Elm for such a long time, I’m baffled by the success of Typescript - it’s hardly more reliable than JS while adding another dependency and much more complexity. For anyone sincerely interested in writing reliable code, not just wanting another toy to play with (Typescript) I can’t image writing front end code in anything other than Elm.

Reliability isn't really part of Typescript's pitch though.

It's maintainability.

Those two qualities aren't mutually exclusive.

typescript is for maintainability inside midsize to enterprise scale companies with the management and hiring challenges associated with that scale (100 to 1000s of engineers), In other words Typescript theoretically solves the problem of how do you catch errors before production when all you have is an army of junior devs?

I find Typescript to be a huge blessing even for my solo work. It's just better than vanilla JS and I can't be convinced otherwise at this point, the evidence is overwhelming.

How do you get one without the other? If typescript weren't (sufficiently) reliable, large projects written in typescript wouldn't be (sufficiently) maintainable.

JS and Elm are at two ends of the spectrum. Typescript is a very nice middle ground. It’s nearly as fast as JS for prototyping, but is much nicer for maintaining. It’s not 100% type safe, but it’s good enough for me. Refactoring and tooling (autocomplete, etc) are really nice in Typescript and beat the pants off JS.

Looking from Elm's side I find TS to be much closer to JS than to the middle ground.

ReasonML/ReScript or F#+Fable or Kotlin.js maybe more closer to what I consider the middel.

JS (which TS is a superset of) if just not a very well designed language.

> I had to stop because [...] and depended on some WebGL 3D and game libraries.

There's a limitation of Elm hidden in there. If your code needs to interoperate with some JavaScript libraries, you need to define an Elm port for each action (i.e. define how Elm sends/receives "messages" to JS). If the Elm-JS messages are few, it's OK, but if not, the process is painful to code and slow to execute.

This is true for interaction between pure functional code and the "outside world". It forces you to state all out assumptions about said interaction up front and often deal explicitly with all possible errors that may arise from your assumptions failing.

Once that is done you can stay mostly in "pure land", which is quite a blissful experience.

This seems more like a network effect than a limitation of Elm. A bunch of libraries are written in JS so of course that's going to be the least friction and fastest way to use them.

That's only half of the story.

Elm prohibits glue code. You can't take well tested JS library, write FFI definitions (like Rescript/Purescript) or typings (like TypeScript) and publish it. You can only publish pure Elm packages. That also means that you can't use WebAPIs if they are not wrapped in packages whitelisted by Elm core team.

There are only two methods to interop with javascript and they both have massive downsides. WebComponents are WebComponents and even then Elm is very picky how you can write those. Ports are nice for heavy/async work but are unusable with small functional-ish APIs like Intl.

> I’m baffled by the success of Typescript

You're baffled, really? The core pitch is that JS developers don't have to learn a whole new language or paradigm such as in the case of other compile-to-JS languages. They can write JS, sprinkle on some TS, and gradually migrate to full TS while learning it along the way. The amount of developer friction is much lower, so that's why it succeeds to a much higher extent (in terms of usage) than other compile-to-JS languages like Elm, PureScript, ReasonML/ReScript, etc.

This exactly matches my experience with Elm. You wrote "..how resistant it was to me hacking my way to success"; the same here, I tried to do things my way, and Elm would resist (thankfully) those efforts. It resulted in an easy to maintain, much cleaner code. Initially, I went through a 3 month mental grind to learn FP in Elm to be somewhat productive. Then it suddenly started to flow. A while ago I wrote a variation of Snake game [0], using elm-ui to render the simple graphics. The coding experience was fantastic.

[0]: https://github.com/holobeat/elm-snake

A few months back I started a feature in an Elm project. I did a few hours of programming and then stopped and forgot about it for two months. When I came back to it I couldn't remember what I was building, and the git branch name wasn't clear either. I decided to just follow the errors and get it to compile again and after about two hours it worked and my frontend sprung back to life with the new feature working. For me Elm is perfect for projects with frequent and extended interruption.

Yes I always consider it and often use it for personal projects for this reason. More time spent up front but it will run forever if I don't touch it. And if I do need to I can just make the change without spending hours fighting js tooling and figuring out what upgrades I need to make etc.

I do group it with clojure, another language I love and have used deeply but intermittently. If I spend a few months away from it when I see the code it's not even "who wrote this and what does it does it do" it's "is this even code what the fuck man."

Agreed. I anticipate the day coming in the not too distant future where I'll have children running around and my time spent on side projects will diminish to a large extent, and become sporadic. I'm very glad to looking forward to having Elm by my side in such a time. (ever-unchanging Elm...how many years ago was it that it pushed a new release? Another bonus for my situation).

> many libraries don’t change much. If it worked three months ago odds are it still works.

LOL when 3 months is considered a long time for a library to not break users, you know something is messed up. I guess the author is referring to the JavaScript ecosystem.

As a Java/Lisp developer, I expect things to keep working essentially forever! Why the hell would they break users every 3 months?!

The unfortunate reality for some of these languages is that the ecosystem moves so fast seeing no git activity for more than a few months is a red flag to find another library.

JavaScript is obviously the elephant in the room here.

I usually guard myself against this by implementing more niche features myself rather than importing them through third party libraries that might get abandoned.

Pin versions and it works forever in Elm too.

It's not a really point in favour or against Elm, and the dep specification is good enough to tackle it.

And "having no new versions" is not considered a good thing in my book.

Elm is great but the authoritarian style of its leadership make things that should be trivial - like installing a custom package - very hard.

When react was immature (aka before hooks) I used elm a fair bit. Nowadays in the age of front-end copy-pasta I just use the framework of the day and sign when I see how slow and patchy TS is.

Two areas where F# might be preferable:

- You can use reflection to generate encoders and decoders. These can be mixed and matched with hand written encoders and decoders.

- You can just throw an exception when unpacking a result or maybe into a value

- You can use “?” and “!!” operators to tell the compiler that the type is correct when working with dynamic objects

> F# might be preferable

For getting something live quick: yes.

But the learning experience of writing some pure-FP code is destroyed by "just throw an exception" and "use “?” and “!!” operators to tell the compiler that the type is correct"

You don't have to use exceptions and other operators with side effects if you don't want to. You can have a pure FP experience with fable and F#. The OP was just mentioning that these escape hatches are available if you need them.

Yes I think they can be removed with linting rules once you are ready to hit production.

I was also sucked into Elm in 2015]/2016 and found it great in some ways but broken in others. If I were to start a new project and wanted that kind of front-end, I'd use Mint: https://www.mint-lang.com/

Why?

JS interop.

Elm’s JS interop isn’t broken.

It's not technically broken, but it's a far cry from this: https://www.mint-lang.com/guide/reference/javascript-interop...

From reading that document, I would say Mint’s JS interop is broken, and Elm’s isn’t.

Being able to write inline JavaScript is certainly not what I want. Perhaps I’m missing something, but inline JavaScript is the kind of thing that will inevitably result in uncaught runtime failure, which is exactly the kind of thing I am trying to avoid by using a language like Elm.

I was initialy excited to try learning Elm, until I saw some of the drama on the GitHub issues and a blog post about leaving the Elm ecosystem after having a bad experience with the project leads (I think [1] was the post).

I've since put it in my little red box of "hot but you'll be better off staying away from", depsite the numerous podcasts praising the incredible effort and design that went into the language. Has anyone got any thoughts on this?

[1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

How much does any drama in any language you use actually effect you?

Wouldn't base my choice on that at all. Learn it to learn something new and expand your horizon if you want to. Or learn it if you think it's valuable to use in its current state (it is). What some people quab about is irrelevant.

When you choose to invest time into something that might end after a flamewar, it grinds your motivation a bit. It's not life critical, but it's in your mind.

There is drama everywhere: on the Linux kernel, on Github, Python, Systemd,... People are getting annoyed all the time

There is different levels of drama and amount of contributors plus funding though.

Do I fear that the Linux kernel, which is used by pretty much all Fortune 500 companies and has a huge amount of paid devs, will die in a huge flamewar? No!

The same doesn't hold true for someones hobby project though.

And I am well aware, that Linux was a hobby project once, doesn't change a thing about current state though.

True, but these are already established tools. So it evens out.

Having followed the language for quite a while, including some of the controversies, I think there's two things you need to be mindful of:

1. The language version starts with 0, i.e. it is being clearly communicated that there is no guarantee of stability

2. The language development is being run by an opinionated BDFL who likes to take his time to think through new features. There's more of novel, well-thought-out ways of doing things, but less support for "I need this for my production use case now"

Neither of those points is inherently bad, but if you plan to adopt Elm in your product or codebase be prepared to rely only on the feature set you get from current version. Expect breaking changes in the future when new version drops.

There's lot to like about the language and it can be a good introduction to functional programming if you are not yet familiar. IMO it is definitely worth spending time on to improve your skillset and to gain new perspectives on programming.

I don't want to claim I am an expert on different programming languages. I really wanted to supplant my JS use-cases with Elm, but the ecosystem is too closed for proper collaboration.

The biggest restriction on adoption is that the language is a gatekeeped brainchild of limited number of devs. They are inclined to build the language around use cases they want, instead of what people who use their language want.

They have effectively closed the gate to having other talented FOSS devs supercharge this language with features that allow it to run circles around other languages currently in production systems (mainly JS)

It's their right to do so if they wish, but it means that I can't consider this language in any serious capacity. It means the language lacks flexibility and reactivity to changing circumstances, and while it describes having a default library without extendible ecosystems as a "feature, not a bug", they've essentially put a ceiling on what is practical with their language in doing so.

I really wanted to like this language, but the more I learned about it, the more I felt disappointed over what could have been.

> if you plan to adopt Elm in your product or codebase be prepared to rely only on the feature set you get from current version. Expect breaking changes in the future when new version drops.

Conversely, though, the language owners also don't get to have it both ways: if they aren't interested in committing to stability and (some measure of) implementing these production use cases, then they should not act, or promote it, as if it is a production-ready project.

That’s quite a strong indictment of most of the JavaScript community/ecosystem.

? I didn't say anything about JavaScript.

I tried to use wit. Evidently I failed.

I see, sorry I missed it.

My personal opinion is that it is a great introduction to functional programming in a front end environment, but the issues that have led to that drama are a huge turn off for production.

There are lots of great typed functional programming tools for the front end with varying levels of type features. All of them offer interoperation with JavaScript in various forms. I am sure there are more that I have not heard of.

Fable (F#)

GHCJS

js_of_ocaml

Purescript

Rescript (formerly ReasonML)

TypeScript

If anything, the insanity just got worse: https://github.com/elm/compiler/issues/1773#issuecomment-418...

There's an open bug re: negative literals, and accusations of bad faith towards the reporter.

Evan is a very difficult person to deal with.

I'm keeping my anonymity on this HN account, but I've clashed with him before on a Github issue on what should have been a trivial routine update.

I didn’t get that sense in reading this. Evan’s concerns seem to be:

1. do other languages allow this? i.e. have other languages prioritized this for development?

2. what are practical situations where it has come up?

Which seem like pretty straightforward questions to ask if you’re trying to prioritize this issue. I get that Evan was a bit curt in asking (2), but I don’t see an accusation of bad faith…

If your language has a pattern grammar where one subset of numeric literals is valid as a pattern and another isn't, your parser is simply broken. There's no question of prioritizing this or "real-world" use cases. It's a basic issue of does this work like any reasonable programmer would expect. The response there is nothing more than "you're holding it wrong"[0].

[0]:https://www.urbandictionary.com/define.php?term=You%27re%20H...

The question is not whether it’s broken or a bad experience. Clearly it is. But software engineers KS stuff like that all the time. The question is: is the cost-benefit worth spending extremely limited resources to address? It is not hateful or dismissive to ask that question.

I’m a bit confused by your interpretation of the dialogue in that thread, especially given that — as I understand it — you are an individual with perhaps a stronger grasp of FP and PLT than anyone else reading this page. I think you can recognise that the design goal and the constraints described in the original comment are nebulous since the most trivial implementation without a case match would have been obviously correct. I don’t know where such an uncharitable interpretation of Evan’s question comes from.

Could you help me understand? What am I missing here?

I feel like this exchange is this skit writ small...https://www.youtube.com/watch?v=sngRrkQayDA. Evan meant a congenial "why are you doing this" as in like..honestly why do they match negative literals? Everyone took it as an accusatory statement that implied "you moron, why would you do such a thing?" which I at first took it that way too so I can totally understand! But on reflection I think he wouldn't react that way and I believe he was just misinterpreted. And by fake examples he meant contrived examples. He wasn't accusing them of acting in bad faith I don't think.

It's a pity, because it may be one of the best ways to get started the pure-FP while also getting some really cool "visible" things built (because it targets the browser).

I'd say forget about the drama and just build something with it. You will probably never notice anything from that drama while learning.

This is an insightful read that gives genuine real-world experience on both the good and frustrating of Elm.

I used elm in my company for more than two years and is not designed for enterprise apps, is great for tiny apps or POC but I, and my entire team, don't recommend this language.

I almost feel the opposite. Even typescript can't stop you from breaking a huge app. With elm it's virtually impossible. I feel much safer in making changes in a big enterprise elm app than a similar js/ts app.

Biggest problem in enterprise context is you need a team that's on board on learning elm. If someone just needs to stop by and make some small changes, it's a bigger hurdle than doing it in a language "everyone" knows.

What makes Elm appealing to me is that is allows me to completely avoid the whole JavaScript ecosystem. There’s no dealing with npm, webpack and all the rest of that confusing mess.

I use Clojurescript for the same reason. I will take any opportunity to stay away from the JS ecosystem.

Sure that's great. But the real advantage is ending up with a repo full of pure-FP code that you can improve/refactor with confidence, right?

Strict compilers make sure my repo only contains code over a certain level of quality. Elm is strict. Code produced in Elm is usually of stellar quality, even by beginners; and if not it's very easy to shape it up later on.

Absolutely, I’m just starting out with Elm and wanting to avoid the JavaScript tooling made Elm stand out. The code quality and helpful compiler is what makes me want to continue to use Elm.

I see it the other way around: I was unable to avoid Javascript, and Elm made it orders of magnitude harder to do that. But I was a n00b working on a side project, so caveat lector!

I wonder if jmtucu meant that elm was hard to teach in an enterprise setting or if you hit wall when your model/codebase reach a certain size.

Both, learning curve was difficult and is impossible to get resources with good/real Elm experience. Also, you end up with a huge Main file in enterprise apps.

Thanks for the details. What stack/lang are the main one used at your company ?

And do you think understanding Elm requires advanced skills / more than senior level ?

Elm is a small and easy language. Certainly much smaller and easier to learn than JavaScript. You should go through the Elm tutorial. It shouldn’t take you long.

Elm use a different paradigm (Functional Programming) and if you are not aware or have experience with it, it will take long time to understand it. The company later moved to React/TS due the issues mentioned above.

I’m on a team with hundreds sharing the same code base is TS.

Few things would make me happier than going back in time and picking a much stricter type system like Elm’s or rescript.

Try F# + Fable instead.

We do this at work and _everybody_ is very happy with it. Works extremely well!

Nice that you had the freedom to choose a great setup

We also use it at our startup (and a few projects before that) and it works great.

We don’t use elmish tho, but the React bindings. Elmish never worked fir us prior little demos.

Yes - a sign of a competent management imho. We're already an F# and C# shop, however, so Fable wasn't such a big leap.

It’s been a hot minute since I did anything in F# (or .NET, for that matter). How’s the compilation speed these days? And how’s the tooling on Linux? The last time I looked, both were painful.

Improved quite a bit, but still isn’t the fastest compiler ever.

Fabel (the F# to JS/Python) compiler is also ok speed wise.

I’m developing on a Mac but have team colleges using linux. Can’t complain. JetBrains Rider is years ahead of Visual Studio IMHO.

any minute now there will be a language that would learn and steal the good parts from elm but with a more open and industrious evolution process. it’s not going to be as good but it’s going to be very-very useful for quite a while, until the next iteration of PL design

I believe that Derw is a good candidate for this. It was announced last month. The creator intends to deliver a better interop with TypeScript/JS, and promises a more open mind (public development of the core language, allow private repositories, etc).

https://derw.substack.com/p/why-derw-an-elm-like-language-th...

thank you, looks interesting. however, the stated goal (elm but easier interop with JS) is for me a bit hard to relate, as I think the boundary will always be more pronounced. but we’ll see where this one goes

my dream not-elm would start with a verbatim fork of elm, an RFC process for changing it, and a safe and powerful language extensions system inspired by Haskell

Roc, but in a few years https://www.roc-lang.org

seems like a good approach to monads, but still hard to judge without a decent textual explanation. thank you for the link

My worry is that a lot what I like about Elm is just not compatible with the normal JS library ownership model. What I like is

a) Very few features, just enough so you can get your work done and there's just one good way to do it. If you don't have a grumpy BDFL then feature creep is inevitable and your language won't be lean and beautiful like Elm (arguably) is.

b) Infrequent releases so that you don't have to reinvent the wheel every few weeks. Elm gets like one release every two years and I very much like it that way. With a big community all helping to develop it rather than (again) one grumpy BDFL who drags their feet all the time there's no way they would be able to have that level of restraint.

but what don't you like about Elm then?

It’s amazing how many developers are personally offended (and I’m not suggesting the author is) when a technology resists them trying to be “clever”. Those same developers might also pay lip service to the idea of writing simple code, because that’s the most mature thing to do, and yet one of the most common criticisms of Elm is that it doesn’t let you try to be clever and do synchronous IO.

That’s a good thing. A very good thing. You can trust the code you write [to a reasonable extent]. You can trust the code your colleagues write [to a reasonable extent], even if they’re relatively junior. Not every change needs to be interrogated like you might have to in the foot-gun factory that is JavaScript.

This level of predictability is amazing for a business, and consequently amazing for a developer’s circadian rhythm if only they could see further than their nose.

Simplicity is extremely undervalued in my opinion. I was previously an evangelist for functional programming with Scala et al., but as my experience grows I become more and more utilitarian. The saying „ With great power comes great responsibility“ fits pretty well in the context of programming languages imho.

That's surprising to me because I would think of scala (and Erlang, elixir etc) as utilitarian fp languages, I refer to them as "working persons languages".

When prototyping I prefer dynamic languages because they allow partial/"sloppy" programs, as generally you type code along the happy path first.

Personally I think it wouldn't hurt if more strongly/statically typed languages took a note from the GHC compiler and had an option like -fdefer-type-errors[1]. That way one can write the sloppy/clever/prototype code, then disable the flag and make the program sturdy in the presence of failure.

[1] https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_gui...

Have you ever leaned on deferring type errors to any significant extent? I’ve been writing Haskell primarily for several years and I tested it out maybe once or twice briefly, but otherwise haven’t found the utility.

I've only used Haskell to experiment with small, gui, command line, networked projects and within that context I did have those flags enabled (deferer type errors and typed holes both proved helpful).

However I've recently switched to chicken scheme for that purpose, not because Haskell isn't good but because of type friction I encounter when trying to use new libraries.

It's not a rant at Haskell, as I assume were I to use it on a daily basis it would be a nice fit. But as I'm using it a couple of times a year, it doesn't work out.

> small, gui, command line, networked projects ... switched to chicken scheme for that purpose

What's your preferred gui library for Chicken for this sort of thing?

No GUI library used thus far, but since I'm using Linux as my target machine for these things it's probably going to be Gtk. Might write my own helper library on top of some raw FFI bindings.

A recent video about -fdefer-type-errors: https://www.youtube.com/watch?v=hPVjA3TO9OI

I prefer the dynamic langs for their "compile" (maybe more accurately "interpret") speed. It helps to keep short change-recompile-reload-check loops during development.

I write a lot of Python, and I mostly agree. But some languages have fast compilers (like Nim and Go), or fast compilers and fast interpreters (like OCaml).

Last night I was playing with an OCaml Web framework called Dream [1]. The change-recompile-reload loops were fast enough that I never had to wait. (OCaml supports separate / incremental compilation, so the benefits tend to scale on larger projects.) It's not a silver bullet, but it might slightly change your mind about why you like dynamic languages. :)

[1] https://aantron.github.io/dream/

Yes I know OCaml compiles fast enough, and lets not forget Elm! Also very fast compiling.

But I find those two a little on the less featurefull side. I think by the time typeclasses are in things get slow really fast. It's features like that, that just add a lot of complexity at compile time.

Just had a look at Dream. Good to see httpaf AND mirage (microkernel) targets! And it allows coding in Reason/Melange, which I find a very nice syntax especially for server-side code. Thanks for mentioning.

Been a while since I coded in Elm but I found the Intellij plugin to be pretty good. Better at least than the VSCode trouble mentioned in the post.

I wonder if Elm had typeclasses if it would help with the verbose code a little. Not having them just means more code but also maybe more someone needs to understand to use the language.

As a Haskell programmer, I am happier that developers who would otherwise be writing JavaScript can more quickly get productive with Elm than I am upset that I don't have the utility of type classes at my fingertips. I think it was a wise compromise.

You'd lose a fair bit of the verbose and helpful error messages for one thing. I think elm seeks to always have the error messages tell you what to do next, and that might be too tough with type classes. Also typeclasses make me act a little too clever. I have a better time when I'm a little more verbose.

Reply on news.ycombinator.com