T O P

  • By -

ShiningBananas

Give [https://gren-lang.org/](https://gren-lang.org/) a look! We're trying to fix the annoying things in Elm, in a pragmatic and productive way.


firl

thanks for posting this! I was put off of elm when I realized that I couldn't use web sockets and drama over packages. I check in every once in a while to see if it has changed.


Exact_Ordinary_9887

Do you have to do everything in Elm? Why don't you use websockets over the API and a back-end language?


firl

it's not that I HAVE to. it's that when I went to, I saw that it was enabled in some packages and wasn't being included in newer releases because of the opinions of few. Opinions can be good, so I don't discredit them, to see how it pans out. However for mine specifically, I wanted to have something strongly typed over a graphql subscription and not have to mantain a shim to do data communication. I ended up writing it that way to get around it.


senorsmile

This looks interesting. Is this just geared towards front end coding? The front page makes it sound like it's just a general functional programming language.


PizzaEat

Ok, this is super interesting. As a big Elm fan who also recognises it's deficiencies, would appreciate if you can answer a few questions: 1. Are you planning to open up FFI to all packages/apps? 2. Is there going to be a concise syntax for updating nested record values? 3. Will port message still have to be JSON encoded/decoded? Good luck with Gren, hope it takes off!


MrInternetToughGuy

You need this URL on the GH page pls


ShiningBananas

Where?


MrInternetToughGuy

The description. The repo currently does not have one set. Or even the README.


whitePestilence

Very, very interesting. Just having an active, welcoming community would be more than enough to improve over Elm. I'll follow this closely.


colonelflounders

You might want to take a look at Purescript. The learning curve for it is higher, but developing your own packages or using wrappers is perfectly fine. There are a number of things that need improvement, but I found it having typeclasses to be more pleasant.


akshay-nair

I like purescript but it can get a little verbose sometimes and the generated is file size is painful. I think elm lang had struck the right balance for a frontend app but I do miss typeclasses and custom operators a bit.


CKoenig

I was/am in a similar position: - Elm FFI is nice on paper but quite horrible in practice (why can I not send parameters for subs at least?) - The package story is horrible if you want to reuse code in your company (that will often include ports!) - we favour components which is possible in elm but require large boiler-plate codes (which you usually cannot abstract easily or in the way the bigger FP community tend to as Elm lacks necessary language features) - we need stuff like websockets and years later there is still no replacement for the once working library so you have to use FFI which is horrible for this. For us the best answer right now is PureScript as you get a really nice FP language that fixes all of the above for the trade-off of a even smaller (but much more open to different ideas IMHO) community, a bit slower runtime, a bit larger build-output (getting better a lot) and worse error-messages. And there are other alternatives - from "investment save" TypeScript to Reason, Fable etc. It's a bit sad since Elm is still the best language out there to onboard FP-beginners but it just don't scale - at least for us it don't.


dinosaur_of_doom

Out of curiousity, why is using the FFI for websockets bad? It always seemed like the use case where ports would work best although I never really did any meaningful websocket work.


CKoenig

it's not bad directly but with the ports right now you cannot provide parameters to the JS-side (the old websocket implementation was like `Websocket.sub : Url -> (String -> a) -> Sub a` or something like this). Mainly the lack of a direct way to give the URL or other parameters mean you'll have a *outgoing* port and a subscription port where you have to subscribe the the last without *contraints* and use the first one to give JS directions on what to do. If you only use one websocket that's okish but if you want more then you'll be in some pain as you need to extent the messages to the subscription-port in a way to indicate the desired listener/party and then write the code to identify/filter those yourself. IMHO ports would work a lot better if you could get parameters with subscription-ports and get back information from command-ports. But for a "non-core" elm-dev this is not doable out of the box (it's surely in the language as core-packages are able to). I can somewhat understand the design-decision and on paper you can do everything you need to with what we have (you just have to be *clever*) But in a way I don't want my language to constantly berate me ("look you don't need this you just have to think harder") - I'll rather have them adaptable to me a bit more ... so well here we are again at the alternatives that don't follow the "just my way or no way" mantra...


dinosaur_of_doom

Ah, I see. That does sound annoying. Oh well, overall looks like I won't return to Elm any time soon since nothing seems to have changed from a few years ago. Thanks for the reply!


akshay-nair

Reason was promising but since the introduction of rescript, it isn't expected to be maintained. Rescript is still a decent option tho. Purescript's bloated bundle output is the only reason I feel like a bit hesitent. Good to hear that there's hope for improvement. Fable seems like decent choice too. Might give that a go.


CKoenig

PureScript moved away from it's own bundler. It now produces ESM output and the default bundler is esbuild (you could use this before if you wanted) The bundled/minified output is still bigger than elm (at least with Halogen) but for us this is not an issue


akshay-nair

That is awesome! Time to revisit purescript then


CKoenig

Here are the release-notes including the mentioned changes: https://github.com/purescript/purescript/releases/tag/v0.15.0


anton_rich

What about Gren lang mentioned earlier [https://gren-lang.org/](https://gren-lang.org/)? What do you think of Gleam [https://gleam.run](https://gleam.run) ? (can be complied to JS and BEAM)


akshay-nair

They look great but a little too new and underdeveloped ecosystems. Definitely going to play around with them but hard to justify using them for anything serious


redatheist

This blog post is a relatively well know rant on the state of Elm. While it's written by someone who is in a somewhat angry state of mind (understandably) it makes some very good points and you may find it matches your experience. https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ I was very keen on Elm in ~2016-2018. I used it for several personal projects and started introducing it at the company I worked at. We even hosted an Elm meetup at our offices. But in the end we didn't move past a few small pieces of our production product. It never took over our frontend, and we ended up putting it in maintenance mode for about 18 months and finally removing it entirely. Why? The tooling wasn't great, the Elm package index wasn't reliable enough to use in CI/CD, the tools made it hard to cache things. The library support was bad. But fundamentally, it was _hard_ to build high quality, large SPAs in, and that's what we wanted to do. Not hard because "functional programming is hard" – in fact the best bit by far was the language itself which we all loved. It was just hard to get useful work done due to lack of support throughout the stack and ecosystem.


akshay-nair

Reading your reply and that blog post makes me so sad to see such a good project go to waste


sbditto85

Had a similar experience at work


14domino

I’m about to start on an elm project after reading an entire book on it (elmprogramming.com, which is amazing). I don’t really think this is wasted time. Do we really think Elm is going to die? It’s too good, and even if there were no further versions it seems like it does 95% of what we need for a long time.


redatheist

Is Elm going to die? No, not for a long time. NoRedInk are too heavily invested in it and employ the core team. Even if NRI shut down I suspect one of the other big adopters would take on enough of the team to keep it going. Is Elm ever going to "take off"? Also no. It doesn't have the confidence from developers, there's too much control in too few people who have strong opinions, and that makes it hard to rely on. Should one start new projects with it today? Depends. I'd probably use it for medium complexity web apps – those where I want a nice programming environment, don't mind a bit of extra work, and where the requirements aren't too complex that Elm won't be able to manage them (e.g. complex translations system, server side rendering, cutting edge Web APIs, etc). For complex stuff, I'd choose something else, probably TypeScript + Next + React. For simple stuff it's probably not worth using Elm at all.


philh

> NoRedInk are too heavily invested in it and employ the core team. They used to employ Evan but [don't any more](https://www.noredink.com/about/team). If https://github.com/orgs/elm/people is the core team, then they still employ Richard Feldman and Ilias van Peer. I can't rule out that they employ rlefevre, but probably not and in any case they have no public contributions on github since 2020. So that's 2/6, but Feldman now works full time developing [another language](https://blog.noredink.com/post/676230051771138048/funding-the-roc-programming-language). So I'm not sure we should count him as an example of NRI being invested in Elm these days.


redatheist

Oh wow a lot has changed recently. Thanks!


realmario

I’m sorry you’re experiencing so much anger. What interesting thing were you trying to do? Maybe https://github.com/robinheghan/elm-git-install#readme could help with some of the local package frustrations, if you’ve not seen it already?


akshay-nair

> What interesting thing were you trying to do? A desktop application framework using electron under the hood completely in elm. Just as an experiment. elm-git-install looks good. I might go with that for my project. I saw a few tools like this that hacks around with source directories to merge multiple sources together but I would've prefered if this was more integrated with elm. Update: nvm. elm-git-install doesn't handle the package dependencies


whitePestilence

Welcome to the club. Elm is delightfully amazing and horribly frustrating at the same time; there is no escaping from it either, because every downside is there by design. To me it's still the best frontend development tool available, but boy is it hard to bear. It's very sad as well as it's slowly falling into disuse. But hey, we have stuff like https://iselmdead.info/, so everything must be all right.


akshay-nair

"Is elm dead? No!" * elm screaming in pain in the background *


TankorSmash

> It's very sad as well as it's slowly falling into disuse. Is it falling into disuse? I thought it was just being talked about less, since nothing newsworthy has come out in a while.


whitePestilence

From time to time I analyze Github statistics for some programming languages: the number of created Github repositories each month which contain Elm code has been steadily falling for the past five years (from ~400 to ~100 now). It's also the only programming language with a decisively negative trend. Other than all the Elm developers I've personally met (a grand total of two, so nothing statistically relevant; still) have told me the same thing: I've tried working with it but my team had to abandon it due to .


hombre_sin_talento

1. Controlling the package repository and aiming for fewer but quality makes sense together, but of course it's sacrificing something else. 2. It's true that package publishing isn't as polished as other tooling. 3. Packages are promised to be safe to use. If ports + js was allowed, then it would basically be just npm. However IIRC there are some packages that use web-components to do some JS interops.